Method and system for gross settlement by use of an opaque blockchain

ABSTRACT

A method for confirmation of an electronic transaction using a blockchain includes: receiving transaction data, the transaction data including a transaction amount and currency code; generating a transaction message formatted based on one or more standards including a first data element configured to store the transaction amount, a second data element configured to store the currency code, and a third data element configured to store an invoice identifier; transmitting the transaction message to a financial institution via a payment network; receiving a return message from the financial institution via the payment network formatted based on the one or more standards and including a data element configured to store the transaction amount, currency code, and invoice identifier; and generating a hash value based on application of hashing algorithms to the transaction amount, currency code, and invoice identifier stored in the data element included in the received return message.

FIELD

The present disclosure relates to gross settlement using an opaqueblockchain, specifically the settlement of electronic transactions usinga blockchain consisting of values generated by hashing capturedelectronic transaction data for fast and secure settlement.

BACKGROUND

When an electronic transaction is conducted between two parties, such asa consumer and a merchant, the consumer may provide their paymentinformation to the merchant in return for goods or services. Themerchant may run the payment information immediately, and the consumermay receive their purchase moments after. However, in many systems,settlement of the transaction between financial institutions on behalfof each of the two parties may take a considerably longer amount oftime, often measured in days. Until the settlement is completed, themerchant does not receive their payment from their financialinstitution, and the charge on the consumer's account with theirfinancial institution is listed as pending.

As a result, it may be beneficial to all entities involved if thesettlement process could be completed faster, as the consumer's accountwould be up-to-date sooner and the merchant would receive their fundsmore quickly. However, existing settlement processes often include therelaying of several transaction messages back and forth across a paymentnetwork. Payment networks typically process hundreds of millions oftransactions each day, each of which requires the routing of at leasttwo transaction messages: an authorization request from an acquirer toan issuer and an authorization response from the issuer back to theacquirer. Due to the urgency of transaction processing, which is oftenmeasured in nano- or milliseconds for consumer and merchant convenience,settlement is often not performed as quickly due to bandwidth andperformance issues, and instead is typically performed during times whentransactions are conducted less frequently.

Thus, existing payment network systems are often unable to performimmediate settlement for electronic transactions due to the vast numberof transactions being processed and bandwidth and resource limits ofexisting systems. As a result, there is a need for a technical solutionwhere settlement of electronic transactions can be performed quickly andwithout added stress on existing payment rails.

SUMMARY

The present disclosure provides a description of systems and methods forconfirming electronic transactions using an opaque blockchain.

A method for confirmation of an electronic transaction using ablockchain includes: receiving, by a receiving device of a processingserver, a data signal superimposed with transaction data, wherein thetransaction data includes data related to an electronic transactionincluding at least a transaction amount and currency code; generating,by a data generation module of the processing server, a transactionmessage for the electronic transaction, wherein the transaction messageis formatted based on one or more standards and includes a plurality ofdata elements including at least a first data element configured tostore the transaction amount, a second data element configured to storethe currency code, and a third data element configured to store aninvoice identifier; electronically transmitting, by a transmittingdevice of the processing server, the generated transaction message to afinancial institution via a payment network; receiving, by the receivingdevice of the processing server, a return message from the financialinstitution via the payment network, wherein the return message isformatted based on the one or more standards and includes at least asingle data element configured to store the transaction amount, currencycode, and invoice identifier; and generating, by a hashing module of theprocessing server, a hash value based on application of one or morehashing algorithms to the transaction amount, currency code, and invoiceidentifier stored in the single data element included in the receivedreturn message.

Another method for confirmation of an electronic transaction using ablockchain includes: receiving, by a receiving device of a processingserver, a transaction message from a financial institution via a paymentnetwork, wherein the transaction message is formatted based on one ormore standards and includes a plurality of data elements including atleast a first data element configured to store the transaction amount, asecond data element configured to store the currency code, and a thirddata element configured to store an invoice identifier; generating, by adata generation module of the processing server, a return message,wherein the return message is formatted based on the one or morestandards and includes at least a single data element configured tostore a transaction amount, currency code, and invoice identifier;generating, by a hashing module of the processing server, a hash valuebased on application of one or more hashing algorithms to thetransaction amount, currency code, and invoice identifier stored in thesingle data element in the generated return message; electronicallytransmitting, by a transmitting device of the processing server, thegenerated return message to the financial institution via the paymentnetwork; and electronically transmitting, by the transmitting device ofthe processing server, the generated hash value to a computing deviceconfigured to post the generated hash value to a blockchain via acommunication network.

A method for storing confirmations of electronic transactions using ablockchain includes: storing, in a memory of a processing server, ablockchain, wherein the blockchain includes a plurality of blocks and,for each block of the plurality of blocks, a header and a plurality oftransaction values, where each transaction value of the plurality oftransaction values is a hash value related to an electronic transactionand generated based on at least a transaction amount, currency code, andinvoice identifier associated with the related electronic transaction;receiving, by a receiving device of the processing server, a set of newhash values, wherein each new hash value is related to an additionalelectronic transaction, and where each new hash value is generated basedon application of one or more hashing algorithms to a transactionamount, currency code, and invoice identifier associated with therespective additional electronic transaction; executing, by a queryingmodule of the processing server, a query on the memory to identify apreceding block of the plurality of blocks included in the blockchainbased on data stored in the header included in each respective block;generating, by a generation module of the processing server, a proof ofwork value based on performing one or more predetermined actions;generating, by the generation module of the processing server, a newblock, wherein the new block includes at least a new header and the setof new hash values, and wherein the new header includes at least areference to the identified preceding block and the generated proof ofwork value; and electronically transmitting, by a transmitting device ofthe processing server, the generated new block to one or more computingdevices associated with the blockchain.

A system for confirmation of an electronic transaction using ablockchain includes: a hashing module of a processing server; areceiving device of the processing server configured to receive a datasignal superimposed with transaction data, wherein the transaction dataincludes data related to an electronic transaction including at least atransaction amount and currency code; a data generation module of theprocessing server configured to generate a transaction message for theelectronic transaction, wherein the transaction message is formattedbased on one or more standards and includes a plurality of data elementsincluding at least a first data element configured to store thetransaction amount, a second data element configured to store thecurrency code, and a third data element configured to store an invoiceidentifier; and a transmitting device of the processing serverconfigured to electronically transmit the generated transaction messageto a financial institution via a payment network. The receiving deviceof the processing server is further configured to receive a returnmessage from the financial institution via the payment network, whereinthe return message is formatted based on the one or more standards andincludes at least a single data element configured to store thetransaction amount, currency code, and invoice identifier. The hashingmodule of the processing server is configured to generate a hash valuebased on application of one or more hashing algorithms to thetransaction amount, currency code, and invoice identifier stored in thesingle data element included in the received return message.

Another system for confirmation of an electronic transaction using ablockchain includes: a receiving device of a processing serverconfigured to receive a transaction message from a financial institutionvia a payment network, wherein the transaction message is formattedbased on one or more standards and includes a plurality of data elementsincluding at least a first data element configured to store thetransaction amount, a second data element configured to store thecurrency code, and a third data element configured to store an invoiceidentifier; a data generation module of the processing server configuredto generate a return message, wherein the return message is formattedbased on the one or more standards and includes at least a single dataelement configured to store a transaction amount, currency code, andinvoice identifier; a hashing module of the processing server configuredto generate a hash value based on application of one or more hashingalgorithms to the transaction amount, currency code, and invoiceidentifier stored in the single data element in the generated returnmessage; and a transmitting device of the processing server configuredto electronically transmit the generated return message to the financialinstitution via the payment network, and electronically transmit thegenerated hash value to a computing device configured to post thegenerated hash value to a blockchain via a communication network.

A system for storing confirmations of electronic transactions using ablockchain includes: a memory of a processing server configured to storea blockchain, wherein the blockchain includes a plurality of blocks and,for each block of the plurality of blocks, a header and a plurality oftransaction values, where each transaction value of the plurality oftransaction values is a hash value related to an electronic transactionand generated based on at least a transaction amount, currency code, andinvoice identifier associated with the related electronic transaction; areceiving device of the processing server configured to receive a set ofnew hash values, wherein each new hash value is related to an additionalelectronic transaction, and where each new hash value is generated basedon application of one or more hashing algorithms to a transactionamount, currency code, and invoice identifier associated with therespective additional electronic transaction; a querying module of theprocessing server configured to execute a query on the memory toidentify a preceding block of the plurality of blocks included in theblockchain based on data stored in the header included in eachrespective block; a generation module of the processing serverconfigured to generate a proof of work value based on performing one ormore predetermined actions, and generate a new block, wherein the newblock includes at least a new header and the set of new hash values, andwherein the new header includes at least a reference to the identifiedpreceding block and the generated proof of work value; and atransmitting device of the processing server configured toelectronically transmit the generated new block to one or more computingdevices associated with the blockchain.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

The scope of the present disclosure is best understood from thefollowing detailed description of exemplary embodiments when read inconjunction with the accompanying drawings. Included in the drawings arethe following figures:

FIG. 1 is a block diagram illustrating a high level system architecturefor the confirmation and gross settlement of electronic transactionsusing an opaque blockchain in accordance with exemplary embodiments.

FIG. 2 is a block diagram illustrating the acquirer processing server ofFIG. 1 for the gross settlement of electronic transactions using anopaque blockchain in accordance with exemplary embodiments.

FIG. 3 is a block diagram illustrating the issuer processing server ofFIG. 2 for the gross settlement of electronic transactions using anopaque blockchain in accordance with exemplary embodiments.

FIGS. 4A and 4B are a flow diagram illustrating a process for theconfirmation and gross settlement of an electronic transaction using anopaque blockchain in accordance with exemplary embodiments.

FIG. 5 is a flow diagram illustrating a process for the gross settlementof an electronic transaction by the acquirer processing server of FIG. 2using an opaque blockchain in accordance with exemplary embodiments.

FIG. 6 is a flow diagram illustrating a process for the gross settlementof an electronic transaction by the issuer processing server of FIG. 3using an opaque blockchain in accordance with exemplary embodiments.

FIG. 7 is a block diagram illustrating an opaque blockchain used in thegross settlement of electronic transactions in accordance with exemplaryembodiments.

FIGS. 8 and 9 are flow charts illustrating exemplary methods forconfirmation of an electronic transaction using a blockchain inaccordance with exemplary embodiments.

FIG. 10 is a flow chart illustrating an exemplary method for storingconfirmation of electronic transactions using a blockchain in accordancewith exemplary embodiments.

FIG. 11 is a flow diagram illustrating the processing of a paymenttransaction in accordance with exemplary embodiments.

FIG. 12 is a block diagram illustrating a computer system architecturein accordance with exemplary embodiments.

Further areas of applicability of the present disclosure will becomeapparent from the detailed description provided hereinafter. It shouldbe understood that the detailed description of exemplary embodiments areintended for illustration purposes only and are, therefore, not intendedto necessarily limit the scope of the disclosure.

DETAILED DESCRIPTION Glossary of Terms

Payment Network— A system or network used for the transfer of money viathe use of cash-substitutes. Payment networks may use a variety ofdifferent protocols and procedures in order to process the transfer ofmoney for various types of transactions. Transactions that may beperformed via a payment network may include product or servicepurchases, credit purchases, debit transactions, fund transfers, accountwithdrawals, etc. Payment networks may be configured to performtransactions via cash-substitutes, which may include payment cards,letters of credit, checks, transaction accounts, etc. Examples ofnetworks or systems configured to perform as payment networks includethose operated by MasterCard®, VISA®, Discover®, American Express®,PayPal®, etc. Use of the term “payment network” herein may refer to boththe payment network as an entity, and the physical payment network, suchas the equipment, hardware, and software comprising the payment network.

Payment Rails—Infrastructure associated with a payment network used inthe processing of payment transactions and the communication oftransaction messages and other similar data between the payment networkand other entities interconnected with the payment network. The paymentrails may be comprised of the hardware used to establish the paymentnetwork and the interconnections between the payment network and otherassociated entities, such as financial institutions, gateway processors,etc. In some instances, payment rails may also be affected by software,such as via special programming of the communication hardware anddevices that comprise the payment rails. For example, the payment railsmay include specifically configured computing devices that are speciallyconfigured for the routing of transaction messages, which may bespecially formatted data messages that are electronically transmittedvia the payment rails, as discussed in more detail below.

Blockchain— A public ledger of all transactions of a blockchain-basedcurrency. One or more computing devices may comprise a blockchainnetwork, which may be configured to process and record transactions aspart of a block in the blockchain. Once a block is completed, the blockis added to the blockchain and the transaction record thereby updated.In many instances, the blockchain may be a ledger of transactions inchronological order, or may be presented in any other order that may besuitable for use by the blockchain network. In some configurations,transactions recorded in the blockchain may include a destinationaddress and a currency amount, such that the blockchain records how muchcurrency is attributable to a specific address. In some instances,additional information may be captured, such as a source address,timestamp, etc. In some embodiments, a blockchain may also consist ofadditional, and in some instances arbitrary, data that is confirmed andvalidated by the blockchain network through proof of work and/or anyother suitable verification techniques associated therewith. In somecases, such data may be included in the blockchain as part oftransactions, such as included in additional data appended totransaction data. In some instances, the inclusion of such data in ablockchain may constitute a transaction. In such instances, a blockchainmay not be directly associated with a specific digital, virtual, fiat,or other type of currency.

System for Confirmation and Gross Settlement Using an Opaque Blockchain

FIG. 1 illustrates a system 100 for the confirmation and grosssettlement of electronic transactions via the use of an opaqueblockchain.

The system 100 may include an acquirer processing server 102. Theacquirer processing server 102, discussed in more detail below, may be acomputing system of an acquiring financial institution, such as anacquiring bank, configured to perform the processes discussed herein forgross settlement of electronic transactions via the use of an opaqueblockchain. The acquiring financial institution associated with theacquirer processing server 102 may possess, manage, issue, or otherwisebe associated with a transaction account associated with a merchant 110for use in receiving funds for electronic transactions. The acquirerprocessing server 102 may be configured to use an opaque blockchain toconfirm settlement of an electronic transaction involving the merchant110 and to increase the balance of the merchant's transaction account bya corresponding amount.

The system 100 may also include an issuer processing server 104. Theissuer processing server 104, discussed in more detail below, may be acomputing system of an issuing financial institution, such as an issuingbank, configured to perform the processes discussed herein for grosssettlement of electronic transactions via the use of an opaqueblockchain. The issuing financial institution associated with the issuerprocessing server 104 may possess, manage, issue, or otherwise beassociated with a transaction account associated with a consumer 106 foruse in funding electronic transactions. The issuer processing server 104may be configured to use an opaque blockchain to confirm settlement ofan electronic transaction involving the consumer 106 and to decrease thebalance of the consumer's transaction account by a corresponding amount.

The issuing financial institution may issue a payment card 108 or otherpayment instrument to the consumer 106 that is associated with theconsumer's transaction account, which may be presented to a merchant 110to convey payment details for use in the processing of an electronicpayment transaction involving the consumer 106 and the merchant 110. Theconsumer 106 may present the payment card 108 to convey payment detailsto the merchant 110 using traditional methods, such as via the readingof a magnetic strip embedded in the payment card 108 encoded withpayment details or the electronic transmission of a data signal from thepayment card 108 superimposed with payment details to a point of salesystem of the merchant 110 using near field communication or othersuitable communication method. Additional methods for conveying paymentdetails may include the use of a mobile computing device equipped withan electronic wallet application program for electronic transmission ofpayment details, the display of a machine-readable code encoded withpayment details by a mobile computing device for reading by the point ofsale system of the merchant 110, etc.

As part of the processing of the electronic transaction, the merchant110 may electronically transmit the payment details received from theconsumer 106 (e.g., via the payment card 108) and additional transactiondata to the acquirer processing server 102. Payment details may include,for instance, a primary account number, expiration date, name, paymentcryptograms, etc. The additional transaction data may include, forexample, a transaction amount, a transaction time, a transaction date,geographic location, merchant category code, consumer data, point ofsale data, merchant data, offer data, reward data, loyalty data, productdata, etc. The payment details and additional transaction data may beelectronically transmitted directly to the acquirer processing server102 or may be transmitted via one or more intermediate entities, such asa gateway process. The payment details and additional transaction datamay be electronically transmitted using the payment rails associatedwith a payment network 112 or via a suitable alternative communicationnetwork. Additional detail regarding the communication of transactiondetails for a payment transaction involving a payment network 112 andthe payment rails are discussed in more detail below with respect to theprocess 1100 illustrated in FIG. 11 .

Once the acquirer processing server 102 receives the payment details andadditional transaction data, the acquirer processing server 102 maygenerate a transaction message for the electronic transaction. Thetransaction message may be a specialized data message that is speciallyformatted pursuant to one or more standards governing the exchange offinancial transaction messages, such as the International Organizationfor Standardization's ISO 8583 standard. The transaction message mayinclude a plurality of data elements configured to store data as setforth in the associated standard(s), such as a data element configuredto store a primary account number, a data element configured to store atransaction amount, etc. The transaction message may also include abitmap configured to store data indicative of the data stored in each ofthe data elements included therein, which may be based on the associatedstandard(s). In some instances, a transaction message may also include amessage type indicator indicative of a type of the transaction message,such as an authorization request.

The transaction message generated by the acquirer processing server 102may include a plurality of data elements configured to store the paymentdetails and additional transaction data. The plurality of data elementsmay include at least a first data element configured to store atransaction amount for the electronic transaction, a second data elementconfigured to store a currency code, and a third data element configuredto store an invoice identifier. The currency code may be indicative ofthe currency associated with the transaction account associated with themerchant 110 or used in the electronic transaction between the merchant110 and consumer 106. The currency code may be included in thetransaction data conveyed by the merchant 110 or may be identified bythe acquirer processing server 102, such as based on the transactionaccount associated with the merchant 110. In some instances, thecurrency code may be included in the payment details, such as based on acurrency associated with the transaction account corresponding to thepayment card 108 presented by the consumer 106. The invoice identifiermay be a value generated or otherwise identified by the acquirerprocessing server 102 that is unique to the electronic transaction beingprocessed, which may be used for identification of transaction messagesand other data associated with the electronic transaction. Thetransaction message may also include a message type indicator indicativeof the transaction message being an authorization request.

The acquirer processing server 102 may electronically transmit thegenerated transaction message to the payment network 112 via the paymentrails. The payment network 112 may forward the transaction message tothe issuer processing server 104, also via the payment rails, foradditional processing. The payment network 112 may be configured toidentify the issuer processing server 104 using one or more traditionalmethods, such as based on a bank identification number included in aprimary account number stored in a corresponding data element includedin the transaction message. In some embodiments, the payment network 112may perform one or more additional services prior to forwarding thetransaction messages, such as fraud detection services, account mappingservices, transaction control services, etc.

The issuer processing server 104 may receive the transaction message andmay determine approval or denial of the related transaction messagebased on data stored therein using traditional methods and systems. Forexample, the issuer processing server 104 may identify a transactionaccount associated with the primary account number stored in acorresponding data element included in the transaction message andidentify if an account balance associated therewith is suitable forfunding the electronic transaction based on the transaction amount forthe electronic transaction, stored in a corresponding data elementincluded in the transaction message. The issuer processing server 104may also determine approval or denial based on, for instance, fraudconsiderations, account settings, transaction controls, credit limits,etc.

If the transaction is approved or declined, the issuer processing server104 may generate a return transaction message. The return transactionmessage may be formatted based on the same standards used in theformatting of the received transaction message. In some instances, thereturn transaction message may be a modification of the receivedtransaction message, such as where one or more data elements includedtherein are modified and where the message type indicator is modified tobe indicative of an authorization response. The return transactionmessage may include a data element configured to store a response code,which may indicate that the related electronic transaction is approvedor declined. The return transaction message may also include anadditional data element configured to store the transaction amount,currency code, and invoice identifier as parsed from the respectivecorresponding data elements included in the received transactionmessage. In some embodiments, the additional data element may beindicated in the associated standard(s) as a data element reserved forprivate use. In some instances, the issuer processing server 104 mayalso be configured to store additional data in the additional dataelement in addition to the currency code, transaction amount, andinvoice identifier, and may format the data stored in the additionaldata element based on a formatting standard agreed upon by the issuerprocessing server 104 and acquirer processing server 102.

Once the return transaction message is generated, the issuer processingserver 104 may electronically transmit the return transaction message tothe payment network 112 via the payment rails. The payment network 112may then perform any necessary services, such as the remapping ofaccount numbers, and may forward the return transaction message to theacquirer processing server 102 via the payment rails. The acquirerprocessing server 102 may electronically transmit a notification to themerchant 110 using the payment rails or a suitable communication networkindicating that the electronic transaction was approved. In someinstances, the notification may comprise the return transaction message.The merchant 110 may receive the notification and may finalize theelectronic transaction with the consumer 106, such as by furnishing thetransacted—for goods or services to the consumer 106.

As part of the gross settlement of the electronic transaction, theissuer processing server 104 may be configured to generate a hash valuefor the electronic transaction. The hash value may be generated byapplying one or more hashing algorithms to the data stored in theadditional data element included in the return transaction message,which includes at least the transaction amount, currency code, andinvoice identifier for the transaction and is formatted using a standardagreed upon between the issuer processing server 104 and the acquirerprocessing server 102. The resulting hash value may be a value unique tothe electronic transaction that is unable to be reversed into theunderlying data via the use of one-way hash functions as the hashingalgorithms with an extremely low likelihood of duplication such that notwo electronic transactions, even among hundreds of millions processedeach day, are likely to return the same hash value.

Once the hash value has been generated by the issuer processing server104, the issuer processing server 104 may electronically transmit thehash value to a blockchain system 114 for posting to an opaqueblockchain. In some embodiments, the issuer processing server 104 oracquirer processing server 102 may be configured to operate as a node inthe blockchain system 114 and may be configured to perform the functionsdiscussed herein for adding the hash value for the electronictransaction to the opaque blockchain.

The blockchain system 114 may receive the hash value for the electronictransaction. The blockchain system 114 may also receive the hash valuesfor additional electronic transactions from the issuer processing server104 and/or the systems of additional issuing financial institutions.Once a predetermined number or size of hash values have been received,the blockchain system 114 may generate a new block to be added to theblockchain. The generation of a new block may include the generation ofa proof-of-work value, which may be generated via the solving of acomplex mathematical problem or other suitable method. In someinstances, the complex mathematical problem may be of a difficulty leveldetermined by one or more computing devices (e.g., nodes) in ablockchain network associated with the blockchain system 114, such as adifficulty level where it may take a predetermined period of time forthe blockchain system 114 or another node in the blockchain network tosolve the mathematical problem, such as ten minutes.

In some embodiments, the new block may also include a reference to apreceding block in the blockchain, such as the most recent block to beadded to the blockchain prior to generation of the new block. The mostrecent block may be determined based on a date of inclusion included ina header of the preceding block, or based on a location of the precedingblock in the blockchain, such as being at an end of the blockchain. Thereference may be an identification number or other value suitable foruse in the identification of a block in the opaque blockchain, such as ahash of a header of the preceding block. The new block may include theproof-of-work value and the reference identifier in a header for thenewly generated block. The new header may also include a transactioncounter, which may indicate the number of hash values being included inthe new block. The remainder of the newly generated block may becomprised of the hash values to be included therein.

Once the block is generated, the blockchain system 114 may append thenewly generated block to the opaque blockchain. In some instances, theblockchain system 114 may electronically transmit the newly generatedblock to one or more nodes associated with the opaque blockchain forinclusion therein, which may confirm the new block (e.g., based on theproof-of-work value included therein) prior to adding the new block tothe opaque blockchain. The blockchain may be considered an opaqueblockchain as the hash values included therein may be opaque in that anyentity may view the hash values included in the blocks comprising theblockchain, but may be unaware of the data represented by the hashvalues due to the use of one-way hashing algorithms.

The acquirer processing server 102 may be configured to generate a hashvalue for the electronic transaction using the data stored in theadditional data element included in the return transaction message. Theacquirer processing server 102 may use the same one or more hashingalgorithms used by the issuer processing server 104 and apply thealgorithms to the data stored in the additional data element to generatea hash value. The generated hash value may be a key in a key-value pair,where the value associated with the hash value are the currency code,transaction amount, and invoice identifier used in the generationthereof. The acquirer processing server 102 may retrieve the blockchainfrom the blockchain system 114 or another node associated with theopaque blockchain, and may then identify if the opaque blockchainincludes the hash value. If the hash value generated by the acquirerprocessing server 102 is the same as a hash value included in the opaqueblockchain, it may serve as confirmation of the electronic transactionas it indicates that the issuer processing server 104 and acquirerprocessing server 102 are in agreement as to the currency type andamount used in the transaction, as well as for which transaction thevalues are associated via the invoice identifier.

Once the transaction is confirmed, the acquirer processing server 102may deposit funds in the transaction account associated with themerchant 110 involved in the electronic transaction based on thetransaction amount associated with that hash value. Similarly, theissuer processing server 104 may confirm the electronic transactionusing the opaque blockchain via a similar method, and may deduct thetransaction amount from the transaction account associated with theconsumer 106 whose payment details were presented to the merchant 110for payment.

By posting the hash value for the electronic transaction to the opaqueblockchain, the acquirer processing server 102 and issuer processingserver 104 can confirm processing of the electronic transaction forsettlement without the use of additional transaction messages conveyedvia the payment network 112 and the associated payment rails. This mayresult in significantly faster settlement, where the transactionaccounts for the consumer 106 and merchant 110 may be settled muchfaster than using traditional methods. In addition, by confirming thetransaction for settlement outside of the payment network 112, thenumber of transaction messages conveyed using the payment network 112and associated payment rails may be drastically reduced, which mayresult in increased performance and processing speed for the processingportion of the transactions. As such, the methods and systems discussedherein may increase the speed of both processing and settlement forelectronic transactions via the use of an opaque blockchain.Furthermore, the use of opaque hash values in the blockchain may ensurethat the data used for confirmation for settlement is easily andpublicly accessible, but without compromising the data indicativethereof via the use of one-way hashing algorithms.

Acquirer Processing Server

FIG. 2 illustrates an embodiment of the acquirer processing server 102of the system 100. It will be apparent to persons having skill in therelevant art that the embodiment of the acquirer processing server 102illustrated in FIG. 2 is provided as illustration only and may not beexhaustive to all possible configurations of the acquirer processingserver 102 suitable for performing the functions as discussed herein.For example, the computer system 1200 illustrated in FIG. 12 anddiscussed in more detail below may be a suitable configuration of theacquirer processing server 102.

The acquirer processing server 102 may include a receiving device 202.The receiving device 202 may be configured to receive data over one ormore networks via one or more network protocols. In some embodiments,the receiving device 202 may be configured to receive data over thepayment rails, such as using specially configured infrastructureassociated with payment networks 112 for the transmission of transactionmessages that include sensitive financial data and information. In someinstances, the receiving device 202 may also be configured to receivedata from merchants 110, payment networks 112, issuer processing servers104, blockchain systems 114, and other entities via alternativenetworks, such as the Internet. In some embodiments, the receivingdevice 202 may be comprised of multiple devices, such as differentreceiving devices for receiving data over different networks, such as afirst receiving device for receiving data over payment rails and asecond receiving device for receiving data over the Internet. Thereceiving device 202 may receive electronically data signals that aretransmitted, where data may be superimposed on the data signal anddecoded, parsed, read, or otherwise obtained via receipt of the datasignal by the receiving device 202. In some instances, the receivingdevice 202 may include a parsing module for parsing the received datasignal to obtain the data superimposed thereon. For example, thereceiving device 202 may include a parser program configured to receiveand transform the received data signal into usable input for thefunctions performed by the processing device to carry out the methodsand systems described herein.

The receiving device 202 may be configured to receive data signalselectronically transmitted by the merchant 110 using a suitablecommunication network, which may be forwarded via one or moreintermediate entities, such as gateway processors, that are superimposedwith payment details and additional transaction data associated withelectronic transactions. The receiving device 202 may also be configuredto receive transaction messages electronically transmitted by thepayment network 112 via the payment rails. The receiving device 202 maybe further configured to receive data signals superimposed with theopaque blockchain or one or more blocks included therein from theblockchain system 114 or other node associated with the opaqueblockchain.

The acquirer processing server 102 may also include a communicationmodule 204. The communication module 204 may be configured to transmitdata between modules, engines, databases, memories, and other componentsof the acquirer processing server 102 for use in performing thefunctions discussed herein. The communication module 204 may becomprised of one or more communication types and utilize variouscommunication methods for communications within a computing device. Forexample, the communication module 204 may be comprised of a bus, contactpin connectors, wires, etc. In some embodiments, the communicationmodule 204 may also be configured to communicate between internalcomponents of the acquirer processing server 102 and external componentsof the acquirer processing server 102, such as externally connecteddatabases, display devices, input devices, etc. The acquirer processingserver 102 may also include a processing device. The processing devicemay be configured to perform the functions of the acquirer processingserver 102 discussed herein as will be apparent to persons having skillin the relevant art. In some embodiments, the processing device mayinclude and/or be comprised of a plurality of engines and/or modulesspecially configured to perform one or more functions of the processingdevice, such as a querying module 222, data generation module 210,hashing module 212, validation module 214, transaction processing module216, etc. As used herein, the term “module” may be software or hardwareparticularly programmed to receive an input, perform one or moreprocesses using the input, and provide an output. The input, output, andprocesses performed by various modules will be apparent to one skilledin the art based upon the present disclosure.

The acquirer processing server 102 may include a transaction database206. The transaction database 206 may be configured to store a pluralityof transaction profiles 208 using a suitable data storage format andschema. The transaction database 206 may be a relational database thatutilizes structured query language for the storage, identification,modifying, updating, accessing, etc. of structured data sets storedtherein. Each transaction profile 208 may be a structured data setconfigured to store data associated with an electronic transactioninvolving the acquirer processing server 102. Each transaction profile208 may include at least a key-value pair comprising a hash value as akey and the transaction amount, currency code, and invoice identifier asthe corresponding value. In some instances, a transaction profile 208may include additional data associated with the related electronictransaction, such as data received from the merchant 110 and/or includedin the transaction messages (e.g., authorization requests and responses)associated therewith, as well as data associated with the settlement ofthe related electronic transaction, such as confirmation of crediting ofthe related merchant transaction account.

The acquirer processing server 102 may include a querying module 222.The querying module 222 may be configured to execute queries ondatabases to identify information. The querying module 222 may receiveone or more data values or query strings, and may execute a query stringbased thereon on an indicated database, such as the transaction database206, to identify information stored therein. The querying module 222 maythen output the identified information to an appropriate engine ormodule of the acquirer processing server 102 as necessary. The queryingmodule 222 may, for example, execute a query on the transaction database206 to identify a transaction profile 208 for use in confirming aprocessed electronic transaction for gross settlement. The transactionprofile 208 may be identified via the use of the hash value, such asidentified in a block in the opaque blockchain, or the invoiceidentifier, such as may be selected by the acquirer processing server102 for settlement following the successful processing of the relatedelectronic transaction. The acquirer processing server 102 may alsoinclude additional databases suitable for use in performing thefunctions discussed herein, such as databases for the storage of dataassociated with merchant transaction accounts for use in settlement ofelectronic transactions.

The acquirer processing server 102 may also include a data generationmodule 210. The data generation module 210 may be configured to generatedata for use by the acquirer processing server 102 for performing thefunctions discussed herein. The data generation module 210 may receivedata and instructions as input, may generate data or data messages basedthereon, and may output the resulting data or data messages to one ormore other engines or modules of the acquirer processing server 102. Forinstance, the data generation module 210 may receive payment details andtransaction data as parsed from a data signal electronically transmittedby the merchant 110 and received by the receiving device 202 for anelectronic transaction, and may generate an invoice identifier for theelectronic transaction as well as a transaction message. The invoiceidentifier may be generated using one or more algorithms designedtherefor, which may include the generation of a random or pseudo-randomnumber for use as the invoice identifier. The transaction message may beformatted based on one or more standards, such as the ISO 8583 standard,and may include a plurality of data elements configured to store data asset forth in the standard(s), which may include a first data elementconfigured to store a transaction amount, a second data elementconfigured to store a currency code, and a third data element configuredto store the invoice identifier.

The acquirer processing server 102 may also include a hashing module212. The hashing module 212 may be configured to generate a hash value.The hashing module 212 may receive data as input, may generate a hash byapplying hashing algorithms to the data, and may output the generatedhash value to one or more other modules or engines of the acquirerprocessing server 102. The hash value may be generated for an electronictransaction and may be generated via the application of one or morehashing algorithms to data stored in an additional data element includedin a transaction message received by the receiving device 202, which maybe an authorization response originating from an issuer processingserver 104 and transmitted via the payment network 112. The data storedin the additional element may comprise at least the transaction amount,currency code, and invoice identifier for the related electronictransaction, and may include additional data and/or may be formatted asagreed upon by the acquirer processing server 102 and issuer processingserver 104.

The acquirer processing server 102 may further include a validationmodule 214. The validation module 214 may be configured to validate(e.g., confirm) an electronic transaction for settlement. The validationmodule 214 may receive one or more data inputs, may validate the inputdata, and may output a result of the validation, such as an indicationof a successful or failed validation. The validation module 214 may beconfigured to receive a hash value stored in a block in the opaqueblockchain, and may be configured to validate the hash value as correctbased on a processed transaction. The correctness of the hash value maybe based on its correspondence to a hash value generated for the sameelectronic transaction by the hashing module 212, which may be stored ina corresponding transaction profile 208 in the transaction database 206(e.g., and identified via the querying module 222). For instance, thevalidation module 214 may validate that the hash value added to theopaque blockchain as generated by the issuer processing server 104 isequivalent to the hash value generated by the hashing module 212 for thesame electronic transaction.

The acquirer processing server 102 may also include a transactionprocessing module 216. The transaction processing module 216 may beconfigured to perform additional functions associated with theprocessing electronic transactions as discussed herein and as will beapparent to persons having skill in the relevant art. For example, thetransaction processing module 216 may be configured to credit orinitiate the crediting of a transaction account associated with amerchant 110 for an electronic transaction for settlement thereoffollowing validation of the transaction by the validation module 214. Inanother example, the transaction processing module 216 may be configuredto perform additional services for an electronic transaction, such asfraud determinations, transaction control evaluation, etc.

The acquirer processing server 102 may also include a transmittingdevice 218. The transmitting device 218 may be configured to transmitdata over one or more networks via one or more network protocols. Insome embodiments, the transmitting device 218 may be configured totransmit data over the payment rails, such as using specially configuredinfrastructure associated with payment networks 112 for the transmissionof transaction messages that include sensitive financial data andinformation, such as identified payment credentials. In some instances,the transmitting device 218 may be configured to transmit data to issuerprocessing servers 104, merchants 110, payment networks 112, blockchainsystems 114, and other entities via alternative networks, such as theInternet. In some embodiments, the transmitting device 218 may becomprised of multiple devices, such as different transmitting devicesfor transmitting data over different networks, such as a firsttransmitting device for transmitting data over the payment rails and asecond transmitting device for transmitting data over the Internet. Thetransmitting device 218 may electronically transmit data signals thathave data superimposed that may be parsed by a receiving computingdevice. In some instances, the transmitting device 218 may include oneor more modules for superimposing, encoding, or otherwise formattingdata into data signals suitable for transmission.

The transmitting device 218 may be configured to electronically transmittransaction messages to the payment network 112 for processing. Thetransmitting device 218 may also be configured to electronicallytransmit return transaction messages or data signals superimposed withnotifications associated with electronic transactions to merchants 110via suitable communication networks. The transmitting device 218 may befurther configured to electronically transmit data signals to theblockchain system 114 that are superimposed with requests for an opaqueblockchain or blocks included therein, for use in confirmation ofelectronic transactions for settlement.

The acquirer processing server 102 may also include a memory 220. Thememory 220 may be configured to store data for use by the acquirerprocessing server 102 in performing the functions discussed herein. Thememory 220 may be configured to store data using suitable dataformatting methods and schema and may be any suitable type of memory,such as read-only memory, random access memory, etc. The memory 220 mayinclude, for example, encryption keys and algorithms, communicationprotocols and standards, data formatting standards and protocols,program code for modules and application programs of the processingdevice, and other data that may be suitable for use by the acquirerprocessing server 102 in the performance of the functions disclosedherein as will be apparent to persons having skill in the relevant art.

Issuer Processing Server

FIG. 3 illustrates an embodiment of the issuer processing server 104 ofthe system 100. It will be apparent to persons having skill in therelevant art that the embodiment of the issuer processing server 104illustrated in FIG. 3 is provided as illustration only and may not beexhaustive to all possible configurations of the issuer processingserver 104 suitable for performing the functions as discussed herein.For example, the computer system 1200 illustrated in FIG. 12 anddiscussed in more detail below may be a suitable configuration of theissuer processing server 104.

The issuer processing server 104 may include a receiving device 302. Thereceiving device 302 may be configured to receive data over one or morenetworks via one or more network protocols. In some embodiments, thereceiving device 302 may be configured to receive data over the paymentrails, such as using specially configured infrastructure associated withpayment networks 112 for the transmission of transaction messages thatinclude sensitive financial data and information. In some instances, thereceiving device 302 may also be configured to receive data fromacquirer processing servers 102, consumers 106, payment networks 112,blockchain systems 114, and other entities via alternative networks,such as the Internet. In some embodiments, the receiving device 302 maybe comprised of multiple devices, such as different receiving devicesfor receiving data over different networks, such as a first receivingdevice for receiving data over payment rails and a second receivingdevice for receiving data over the Internet. The receiving device 302may receive electronically data signals that are transmitted, where datamay be superimposed on the data signal and decoded, parsed, read, orotherwise obtained via receipt of the data signal by the receivingdevice 302. In some instances, the receiving device 302 may include aparsing module for parsing the received data signal to obtain the datasuperimposed thereon. For example, the receiving device 302 may includea parser program configured to receive and transform the received datasignal into usable input for the functions performed by the processingdevice to carry out the methods and systems described herein.

The receiving device 302 may be configured to receive transactionmessages electronically transmitted by the payment network 112 via thepayment rails. The receiving device 202 may also be configured toreceive data signals from the blockchain system 114 that aresuperimposed with the opaque blockchain or blocks included therein.

The issuer processing server 104 may also include a communication module304. The communication module 304 may be configured to transmit databetween modules, engines, databases, memories, and other components ofthe issuer processing server 104 for use in performing the functionsdiscussed herein. The communication module 304 may be comprised of oneor more communication types and utilize various communication methodsfor communications within a computing device. For example, thecommunication module 304 may be comprised of a bus, contact pinconnectors, wires, etc. In some embodiments, the communication module304 may also be configured to communicate between internal components ofthe issuer processing server 104 and external components of the issuerprocessing server 104, such as externally connected databases, displaydevices, input devices, etc. The issuer processing server 104 may alsoinclude a processing device. The processing device may be configured toperform the functions of the issuer processing server 104 discussedherein as will be apparent to persons having skill in the relevant art.In some embodiments, the processing device may include and/or becomprised of a plurality of engines and/or modules specially configuredto perform one or more functions of the processing device, such as aquerying module 322, data generation module 310, hashing module 312,validation module 314, transaction processing module 316, etc. As usedherein, the term “module” may be software or hardware particularlyprogrammed to receive an input, perform one or more processes using theinput, and provide an output. The input, output, and processes performedby various modules will be apparent to one skilled in the art based uponthe present disclosure.

The issuer processing server 104 may include a transaction database 306.The transaction database 306 may be configured to store a plurality oftransaction profiles 308 using a suitable data storage format andschema. The transaction database 306 may be a relational database thatutilizes structured query language for the storage, identification,modifying, updating, accessing, etc. of structured data sets storedtherein. Each transaction profile 308 may be a structured data setconfigured to store data associated with an electronic transactioninvolving the issuer processing server 104. Each transaction profile 308may include at least a key-value pair comprising a hash value as a keyand the transaction amount, currency code, and invoice identifier as thecorresponding value. In some instances, a transaction profile 308 mayinclude additional data associated with the related electronictransaction, such as data included in the transaction messages (e.g.,authorization requests and responses) associated therewith, as well asdata associated with the settlement of the related electronictransaction, such as confirmation of debiting of the related consumertransaction account. The issuer processing server 104 may also includeadditional databases suitable for use in performing the functionsdiscussed herein, such as databases for the storage of data associatedwith consumer transaction accounts for use in settlement of electronictransactions.

The issuer processing server 104 may include a querying module 322. Thequerying module 322 may be configured to execute queries on databases toidentify information. The querying module 322 may receive one or moredata values or query strings, and may execute a query string basedthereon on an indicated database, such as the transaction database 306,to identify information stored therein. The querying module 322 may thenoutput the identified information to an appropriate engine or module ofthe issuer processing server 104 as necessary. The querying module 322may, for example, execute a query on the transaction database 306 toidentify a transaction profile 308 for use in confirming a processedelectronic transaction for gross settlement. The transaction profile 308may be identified via the use of the hash value, such as identified in ablock in the opaque blockchain, or the invoice identifier, such as maybe selected by the issuer processing server 104 for settlement followingthe successful processing of the related electronic transaction.

The issuer processing server 104 may also include a data generationmodule 310. The data generation module 310 may be configured to generatedata for use by the issuer processing server 104 for performing thefunctions discussed herein. The data generation module 310 may receivedata and instructions as input, may generate data or data messages basedthereon, and may output the resulting data or data messages to one ormore other engines or modules of the issuer processing server 104. Forinstance, the data generation module 310 may receive a transactionmessage originating from the acquirer processing server 102 and receivedby the receiving device 302 as input. The transaction message may beformatted based on one or more standards, such as the ISO 8583 standard,and may include a plurality of data elements configured to store data asset forth in the standard(s), which may include a first data elementconfigured to store a transaction amount, a second data elementconfigured to store a currency code, and a third data element configuredto store the invoice identifier.

The data generation module 310 may be configured to generate a returntransaction message, which may be a modification of the receivedtransaction message that also include a data element configured to storea response code and an additional data element configured to store atleast the transaction amount, currency code and invoice identifier. Insome instances, the data generation module 310 may generate a data setfor storage in the additional data element that includes the transactionamount, currency code, and invoice identifier, which may also includeadditional data or may be formatted as agreed upon by the issuerprocessing server 104 and the acquirer processing server 102. In someinstances, the data stored in the corresponding data elements of thereturn transaction message, such as the response code, may be based oninstructions or data received by the data generation module 310 fromanother engine or module of the issuer processing server 104, such as atransaction processing module 316.

The issuer processing server 104 may also include a hashing module 312.The hashing module 312 may be configured to generate a hash value. Thehashing module 312 may receive data as input, may generate a hash byapplying hashing algorithms to the data, and may output the generatedhash value to one or more other modules or engines of the issuerprocessing server 104. The hash value may be generated for an electronictransaction and may be generated via the application of one or morehashing algorithms to data stored in the additional data elementincluded in the generated return transaction message generated by thedata generation module 310. The data stored in the additional elementmay comprise at least the transaction amount, currency code, and invoiceidentifier for the related electronic transaction, and may includeadditional data and/or may be formatted as agreed upon by the acquirerprocessing server 102 and issuer processing server 104.

The issuer processing server 104 may further include a validation module314. The validation module 314 may be configured to validate (e.g.,confirm) an electronic transaction for settlement. The validation module314 may receive one or more data inputs, may validate the input data,and may output a result of the validation, such as an indication of asuccessful or failed validation. The validation module 314 may beconfigured to receive a hash value stored in a block in the opaqueblockchain, and may be configured to validate the hash value as correctbased on a processed transaction. The correctness of the hash value maybe based on its correspondence to a hash value generated for the sameelectronic transaction by the hashing module 312, which may be stored ina corresponding transaction profile 308 in the transaction database 306(e.g., and identified via the querying module 322). For instance, thevalidation module 314 may validate that the hash value added to theopaque blockchain as generated by the issuer processing server 104 isequivalent to the hash value generated by the hashing module 312 for thesame electronic transaction.

The issuer processing server 104 may also include a transactionprocessing module 316. The transaction processing module 316 may beconfigured to perform additional functions associated with theprocessing electronic transactions as discussed herein and as will beapparent to persons having skill in the relevant art. For example, thetransaction processing module 316 may be configured to debit or initiatethe debiting of a transaction account associated with a consumer 106 foran electronic transaction for settlement thereof following validation ofthe transaction by the validation module 314. In another example, thetransaction processing module 316 may be configured to performadditional services for an electronic transaction, such as frauddeterminations, transaction control evaluation, etc.

The issuer processing server 104 may also include a transmitting device318. The transmitting device 318 may be configured to transmit data overone or more networks via one or more network protocols. In someembodiments, the transmitting device 318 may be configured to transmitdata over the payment rails, such as using specially configuredinfrastructure associated with payment networks 112 for the transmissionof transaction messages that include sensitive financial data andinformation, such as identified payment credentials. In some instances,the transmitting device 318 may be configured to transmit data toacquirer processing servers 102, consumer 106, payment networks 112,blockchain systems 114, and other entities via alternative networks,such as the Internet. In some embodiments, the transmitting device 318may be comprised of multiple devices, such as different transmittingdevices for transmitting data over different networks, such as a firsttransmitting device for transmitting data over the payment rails and asecond transmitting device for transmitting data over the Internet. Thetransmitting device 318 may electronically transmit data signals thathave data superimposed that may be parsed by a receiving computingdevice. In some instances, the transmitting device 318 may include oneor more modules for superimposing, encoding, or otherwise formattingdata into data signals suitable for transmission.

The transmitting device 318 may be configured to electronically transmittransaction messages to the payment network 112 for processing, such asreturn transaction messages generated by the data generation module 210.The transmitting device 318 may also be configured to electronicallytransmit hash values generated by the hashing module 312 to blockchainsystems 114 for inclusion in the opaque blockchain. The transmittingdevice 318 may be further configured to electronically transmit datasignals to the blockchain system 114 that are superimposed with requestsfor an opaque blockchain or blocks included therein, for use inconfirmation of electronic transactions for settlement.

The issuer processing server 104 may also include a memory 320. Thememory 320 may be configured to store data for use by the issuerprocessing server 104 in performing the functions discussed herein. Thememory 320 may be configured to store data using suitable dataformatting methods and schema and may be any suitable type of memory,such as read-only memory, random access memory, etc. The memory 320 mayinclude, for example, encryption keys and algorithms, communicationprotocols and standards, data formatting standards and protocols,program code for modules and application programs of the processingdevice, and other data that may be suitable for use by the issuerprocessing server 104 in the performance of the functions disclosedherein as will be apparent to persons having skill in the relevant art.

In some embodiments, the issuer processing server 104 may be configuredto operate as the blockchain system 114 for the addition of hash valuesinto the opaque blockchain via inclusion in new blocks. In such anembodiment, the receiving device 302 may be configured to receive datasignals superimposed with hash values from additional issuer processingservers 104, may utilize hash values generated internally via thehashing module 312, or a combination thereof. The data generation module310 may be configured to generate a new block for inclusion in theopaque blockchain.

The new block may comprise at least a header and plurality of hashvalues related to processed electronic transactions. The header mayinclude at least a reference identifier referring to a preceding blockin the opaque blockchain and a proof-of-work value. The referenceidentifier referring to the preceding block may be identified via theexecution of a query by the querying module 322 on the opaque blockchainfor identification thereof. The reference identifier may be included ina header of the preceding block, or may be generated using the header ordata included therein via application thereof to a hashing algorithm bythe hashing module 312. The preceding block may be identified based onits position in the blockchain or data included in the header, such as ageneration or inclusion date included therein. The proof-of-work valuemay be generated by the data generation module 310, and may be generatedas a solution to a complex mathematical problem, whose difficulty levelmay be set by the issuer processing server 104, acquirer processingserver 102, blockchain system 114, one or more additional nodesassociated with the opaque blockchain, or a combination thereof.

Once the new block is generated, the block may be added to the opaqueblockchain. In some instances, the memory 320 may be configured to storethe opaque blockchain, and the block may be added via the execution of aquery suitable therefor by the querying module 322 of the issuerprocessing server 104. In other instances, the transmitting device 318may electronically transmit the block to one or more nodes associatedwith the opaque blockchain for confirmation thereof prior to beingappended to the opaque blockchain.

Process for Confirming an Electronic Transaction Using an OpaqueBlockchain for Settlement

FIGS. 4A and 4B illustrate a process for conducting and confirming anelectronic transaction via the use of an opaque blockchain forsettlement thereof.

In step 402, the receiving device 202 of the acquirer processing server102 may receive transaction data from a merchant 110. The transactiondata may include payment details and additional transaction data relatedto an electronic transaction involving the merchant 110 and a consumer106. The transaction data may be electronically transmitted via asuitable communication network, and may be transmitted directly from themerchant 110 or through one or more intermediate entities, such asgateway processors.

In step 404, the data generation module 210 of the acquirer processingserver 102 may generate an invoice identifier for the electronictransaction. The invoice identifier may be a value unique to theelectronic transaction, such as a randomly generated number oralphanumeric value that has not been previously generated or otherwiseidentified for an electronic transaction. In step 406, the datageneration module 210 may generate a transaction message for theelectronic transaction. The transaction message may be formatted basedon one or more standards, such as the ISO 8583 standard, and include amessage type indicator indicative of an authorization request and aplurality of data elements including at least a first data elementconfigured to store a transaction amount, a second data elementconfigured to store a currency code, and a third data element configuredto store the invoice identifier.

In step 408, the transmitting device 218 of the acquirer processingserver 102 may electronically transmit the authorization request to theissuer processing server 104 via the payment network 112 using thepayment rails. In step 410, the receiving device 302 of the issuerprocessing server 104 may receive the authorization request from thepayment network 112 using the payment rails. In step 412, thetransaction processing module 316 may perform traditional processes inapproving the electronic payment transaction, such as by determiningthat there is a low likelihood of fraud for the transaction and that thetransaction account presented for payment has a sufficient balance tocover the transaction amount for the transaction.

In step 414, the data generation module 310 of the issuer processingserver 104 may generate a return transaction message for the electronictransaction, such as by generating a new data message or modifying thereceived authorization request accordingly. The return transactionmessage may be formatted using the same one or more standards used informatting the authorization request and include a message typeindicator indicative of an authorization response and a plurality ofdata elements, including a data element configured to store a responsecode indicative of approval and an additional data element configured tostore at least the transaction amount, currency code, and invoiceidentifier, which may include additional data and/or be formatted asagreed upon by the acquirer processing server 102 and issuer processingserver 104.

In step 416, the hashing module 312 of the issuer processing server 104may generate a hash value for the electronic transaction. The hash valuemay be generated by the application of one or more hashing algorithms tothe data stored in the additional data element included in the generatedauthorization response. In step 418, the transmitting device 318 of theissuer processing server 104 may electronically transmit the hash valueto the blockchain system 114 for posing to the opaque blockchain. Insome embodiments, the modules and engines of the issuer processingserver 104 may be configured to generate a new block for the opaqueblockchain that includes the hash value using the methods discussedherein for posting to the opaque blockchain.

In step 420, the transmitting device 318 of the issuer processing server104 may electronically transmit the authorization response to theacquirer processing server 102 via the payment network 112 using thepayment rails. In some embodiments, step 420 may be performed prior toor concurrently with steps 416 and 418. In step 422, the receivingdevice 202 of the acquirer processing server 102 may receive theauthorization response from the payment network 112 via the paymentrails. The acquirer processing server 102 may then perform anyadditional steps necessary as performed in traditional transactionprocessing, such as illustrated in the process 1100 of FIG. 11 anddiscussed below. In step 424, the hashing module 212 of the acquirerprocessing server 102 may generate a hash value by applying the one ormore hashing algorithms used by the issuer processing server 104 to thedata stored in the additional data element included in the receivedauthorization response, which may include at least the transactionamount, currency code, and invoice identifier.

In step 426, the receiving devices 202 and 302 of the acquirerprocessing server 102 and issuer processing server 104, respectively,may each receive the opaque blockchain or one or more blocks includedtherein from the blockchain system 114, including a block that includesthe hash value posted to the opaque blockchain as provided by the issuerprocessing server 104. In step 428, the validation modules 214 and 314of the acquirer processing server 102 and issuer processing server 104,respectively, may validate the hash value included in the block of theopaque blockchain as being equivalent to the value generated by therespective data generation modules 210 and 310 using the data stored inthe additional data element of the authorization response. Uponsuccessful validation, in step 430, the transaction processing module216 of the acquirer processing server 102 may credit the transactionaccount associated with the merchant 110 involved in the electronictransaction for the transaction amount. In step 432, the transactionprocessing module 316 of the issuer processing server 104 may debit thetransaction account associated with the consumer 106 involved in theelectronic transaction for the transaction amount. In step 434, theacquirer processing server 102 and issuer processing server 104 mayperform any additional actions suitable for the further settlement ofthe electronic transaction, such as by transferring the transactionamount from the issuing financial institution to the acquiring financialinstitution, or updating account records accordingly.

Acquirer Processing and Confirmation of Electronic Transactions Using anOpaque Blockchain

FIG. 5 illustrates a process 500 for the confirmation of an electronictransaction and settlement thereof for an acquiring financialinstitution via the use of an opaque blockchain.

In step 502, the receiving device 202 of the acquirer processing server102 may receive transaction data for an electronic transaction from amerchant 110, which may include payment details and additionaltransaction data, including at least a transaction amount and a currencycode, and may be transmitted via one or more gateway processors or otherintermediate entities. In step 504, the transaction processing module216 of the acquirer processing server 102 may determine if thetransaction is to be settled via the opaque blockchain. Thedetermination may be based on account preferences or settings for thetransaction account associated with the merchant 110, criteria asapplied to the transaction data received from the merchant 110, or othersuitable criteria. For example, the acquirer processing server 102 maydetermine that any transactions under a specific transaction amount orinvolving a specific merchant industry may be settled via the opaqueblockchain.

If the electronic transaction is not to be settled via the opaqueblockchain, then, in step 506, the transaction processing module 216 andother modules and engines of the acquirer processing server 102 mayproceed to process the electronic transaction using traditional methods,such as illustrated in the process 1100 of FIG. 11 and discussed in moredetail below. If the electronic transaction is to be settled using theopaque blockchain, then, in step 508, the data generation module 210 ofthe acquirer processing server 102 may generate an invoice identifierthat is uniquely associated with the electronic transaction. In step510, the data generation module 210 of the acquirer processing server102 may generate a transaction message for the electronic transaction,where the transaction message is formatted based on one or morestandards, such as the ISO 8583 standard, and includes a message typeindicator indicative of an authorization request and a plurality of dataelements including at least a first data element configured to store thetransaction amount, a second data element configured to store thecurrency code, and a third data element configured to store the invoiceidentifier.

In step 512, the transmitting device 218 of the acquirer processingserver 102 may electronically transmit the authorization request to theissuing financial institution involved in the electronic transaction viathe payment network 112 using the payment rails. In step 514, thereceiving device 202 of the acquirer processing server 102 may receivean authorization response from the issuing financial institution via thepayment network 112 using the payment rails. The authorization responsemay be a return transaction message formatted using the same one or morestandards that includes a message type indicator indicative of anauthorization response and include a plurality of data elementsincluding a data element configured to store a response code and anadditional data element configured to store additional data, comprisingat least the transaction amount, currency code, and invoice identifier,which may include additional data and/or be formatted as agreed upon bythe acquirer processing server 102 and the issuer processing server 104.

In step 516, the transaction processing module 216 of the acquirerprocessing server 102 may determine if the electronic transaction wasapproved by the issuing financial institution. The determination may bebased on the response code stored in the corresponding data elementincluded in the authorization response, which may indicate if theelectronic transaction was approved or declined by the issuing financialinstitution. If the electronic transaction was declined, then, in step518, the transmitting device 218 of the acquirer processing server 102may electronically transmit a data signal superimposed with anotification indicating that the transaction was declined to themerchant 110. In some instances, the authorization response may betransmitted as the notification.

If, in step 516, the transaction processing module 216 of the acquirerprocessing server 102 determines that the electronic transaction wasapproved, then, in step 520, the hashing module 212 of the acquirerprocessing server 102 may generate a hash value for the electronictransaction for use in the settlement. The hash value may be generatedby the application of one or more hashing algorithms to the data storedin the additional data element included in the received authorizationresponse. In step 522, a key-value pair may be stored in a transactionprofile 208 of the transaction database 206 of the acquirer processingserver 102, such as via execution of a query suitable therefor by aquerying module 222 of the acquirer processing server 102. The key-valuepair may include the hash value as a key and the data used in thegeneration thereof as the corresponding value in the pair.

In step 524, the receiving device 202 of the acquirer processing server102 may receive the opaque blockchain from the blockchain system 114using a suitable communication network. The opaque blockchain, discussedin more detail below, may include a plurality of blocks. Each block mayinclude at least a header and one or more transaction values. The headermay include at least a reference identifier and a proof-of-work value,and may also include a transaction counter indicative of a number oftransaction values in the block. Each transaction value may be a hashvalue generated for an electronic transaction using the transactionamount, currency code, and invoice identifier for that transaction.

In step 526, the validation module 214 of the acquirer processing server102 may determine if the electronic transaction is validated based onthe opaque blockchain. The validation may include determining if atransaction value is included in the blockchain that correspondsdirectly to the hash value generated by the hashing module 212 in step520. The inclusion of such a transaction value in the blockchain mayindicate that the issuing financial institution received and hashed thesame transaction amount, currency code, and invoice identifier, thusimplying agreement to the values for settlement of the transaction. Ifthe validation is unsuccessful, then settlement may not be performed. Ifthe validation is successful, then, in step 528, the transactionprocessing module 216 of the acquirer processing server 102 may performany actions suitable for settlement of the transaction, such as thecrediting of the transaction amount to the transaction accountassociated with the merchant 110 and the receipt of the transactionamount from the issuing financial institution.

Issuer Processing and Confirmation of Electronic Transactions Using anOpaque Blockchain

FIG. 6 illustrates a process 600 for the confirmation of an electronictransaction and settlement thereof for an issuing financial institutionvia the use of an opaque blockchain.

In step 602, the receiving device 302 of the issuer processing server104 may receive an authorization request for an electronic transaction.The authorization request may be received from a payment network 112 viathe payment rails, and may originate from an acquirer processing server102 associated with a merchant 110 involved in the electronictransaction. The authorization request may be a transaction messageformatted pursuant to one or more standards, such as the ISO 8583standard, and include a message type indicator indicative of anauthorization request and a plurality of data elements, including atleast a first data element configured to store a transaction amount, asecond data element configured to store a currency code, and a thirddata element configured to store an invoice identifier.

In step 604, a transaction processing module 316 of the issuerprocessing server 104 may identify an account profile for a transactionaccount associated with a consumer 106 involved in the electronictransaction. The account profile may be identified via the querying of acorresponding database by a querying module 322 of the issuer processingserver 104 using a primary account number or other data included incorresponding data elements included in the authorization response. Instep 606, the transaction processing module 316 of the issuer processingserver 104 may determine if the transaction is approved. Approval of thetransaction may be based on traditional methods, which may take intoaccount fraud considerations, transaction controls, account balances andcredit limits for the transaction account, etc. If the transaction isnot approved, then, in step 608, the data generation module 310 of theissuer processing server 104 may generate an authorization responseindicating that the transaction is declined, which may be forwarded tothe payment network 112, using traditional methods and systems.

If the electronic transaction is to be approved, then, in step 610 thedata generation module 310 issuer processing server 104 may generate anauthorization response indicating approval. The authorization responsemay be a newly generated transaction message, or a modification of thereceived authorization request, that includes a message type indicatorindicative of an authorization response and a plurality of data elementsincluding at least a data element configured to store a response codeindicating that the transaction was approved and an additional dataelement configured to store the transaction amount, currency code, andinvoice identifier, which may also include and/or be formatted as agreedupon by the issuer processing server 104 and acquirer processing server102. In some instances, the additional data element may be a dataelement reserved for private use as set forth in the associatedstandard(s). In step 611, the transmitting device 318 of the issuerprocessing server 104 may electronically transmit the authorizationresponse to the payment network 112 for additional processing of theelectronic transaction.

In step 612, the transaction processing module 316 issuer processingserver 104 may determine if the electronic transaction is to be settledvia the opaque blockchain. In some instances, the determination may bebased on data stored in a corresponding data element included in thereceived authorization response, such as a value set by the acquirerprocessing server 102 indicating the method for settlement. In otherinstances, the determination may be based on additional transactiondata, such as the transaction amount, merchant data, consumer data, etc.If the transaction is not to be settled using the blockchain, then, instep 616, the transaction processing module 316 may settle thetransaction using traditional methods involving the payment network 112.

If the transaction is to be settled with the blockchain, then, in step620, the hashing module 312 of the issuer processing server 104 maygenerate a hash value for the electronic transaction. The hash value maybe generated via the application of one or more hashing algorithms tothe data stored in the additional data element included in the generatedauthorization response. In some embodiments, step 612 may be performedprior to step 611 such that the authorization response may not includethe data stored in the additional data element used to generate the hashvalue if the electronic transaction is to be settled usingbusiness-as-usual (BAU) processes.

In step 622, the generated hash value may be posted to the opaqueblockchain associated with the blockchain system 114. In someembodiments, the posting of the hash value may include electronicallytransmitting the hash value to a blockchain system 114 associated withthe opaque blockchain using the transmitting device 318. In otherembodiments, the issuer processing server 104 may be configured togenerate a new block for the opaque blockchain for inclusion thereinusing the methods discussed herein. In step 624, the receiving device302 of the issuer processing server 104 may receive the opaqueblockchain from the blockchain system 114 that includes a new blockincluding the electronic transaction's hash value following verificationof the opaque blockchain by one or more nodes associated therewith.

In step 626, the validation module 314 of the issuer processing server104 may determine if the electronic transaction is successfullyvalidated based on the opaque blockchain. The validation may be based onthe inclusion of a hash value in a block of the opaque blockchain thatcorresponds to the hash value generated for the electronic transactionin step 620 using the data stored in the additional data elementincluded in the authorization response. If the validation isunsuccessful, then the process may be completed and settlement may notoccur. If validation is successful, then, in step 628, the transactionprocessing module 316 issuer processing server 104 may perform thesettlement, which may include the debiting of a transaction account usedin the electronic transaction for the transaction amount and thetransmission of funds to the acquiring financial institution.

Opaque Blockchain

FIG. 7 illustrates a configuration of the opaque blockchain used hereinfor the confirmation of electronic transactions for settlement. It willbe apparent to persons having skill in the relevant art that theconfiguration illustrated in FIG. 7 and discussed herein is provided asan illustration only, and that additional configures of the opaqueblockchain may be suitable for performing the functions discussedherein.

As illustrated in FIG. 7 , an opaque blockchain 702 may be comprised ofa plurality of blocks 704. Each block 704 comprising the opaqueblockchain 702 may be comprised of a header 706 and a plurality oftransaction values 708. Each transaction value 708 may correspond to ahash value generated for an electronic transaction. The hash value maybe generated via the application of one or more hashing algorithms todata associated with the related electronic transaction including atleast a transaction amount, currency code, and invoice identifier. Thehash value may be generated using one-way hashes such that only entities(e.g., the acquiring and issuing financial institutions involved in therelated electronic transaction) in possession of the correct set of dataused to generate the hash value may understand what the hash valuerepresents.

Each header 706 may include data associated with the respective block704. A header 706 may include, for example, a reference identifier 710.The reference identifier 710 may be a unique value associated with therespective block 704 suitable for use in the identification thereof. Aheader 706 may also, or alternatively, include a preceding reference712. The preceding reference 712 may be an identifier associated with apreceding block in the opaque blockchain 702. In some instances, thepreceding reference 712 may be a hash of the header 706 for thepreceding block. In such instances, the header 706 may not include areference identifier 710 as the respective block 704 may be identifiedvia a hash of the header 706.

A header 706 may also include a proof of work value 714. The proof ofwork value 714 may be a solution to a complex mathematical problem. Thecomplex mathematical problem may be of a difficulty level determined beone or more nodes or blockchain systems 114 associated with the opaqueblockchain 702 that is suitable for the continued generation andaddition of blocks 704 to the opaque blockchain 702. For example, thecomplex mathematical problem may be a problem designed such that asolution is determined near a predetermined interval of time, such asevery ten minutes. In some embodiments, a header 706 may also include atransaction counter, which may be indicative of the number oftransaction values 708 in the respective block 704.

First Exemplary Method for Confirmation of an Electronic TransactionUsing a Blockchain

FIG. 8 illustrates a method 800 for the confirmation of an electronictransaction by an acquiring financial institution for settlement via theuse of an opaque blockchain.

In step 802, a data signal superimposed with transaction data may bereceived by a receiving device (e.g., the receiving device 202) of aprocessing server (e.g., the acquirer processing server 102), whereinthe transaction data includes data related to an electronic transactionincluding at least a transaction amount and currency code. In step 804,a transaction message may be generated by a data generation module(e.g., the data generation module 210) of the processing server for theelectronic transaction, wherein the transaction message is formattedbased on one or more standards and includes a plurality of data elementsincluding at least a first data element configured to store thetransaction amount, a second data element configured to store thecurrency code, and a third data element configured to store an invoiceidentifier.

In step 806, the generated transaction message may be electronicallytransmitted by a transmitting device (e.g., the transmitting device 218)of the processing server to a financial institution via a paymentnetwork (e.g., the payment network 112). In step 808, a return messagemay be received by the receiving device of the processing server fromthe financial institution via the payment network, wherein the returnmessage is formatted based on the one or more standards and includes atleast a single data element configured to store the transaction amount,currency code, and invoice identifier. In step 810, a hash value may begenerated by a hashing module (e.g., the hashing module 212) of theprocessing server based on application of one or more hashing algorithmsto the transaction amount, currency code, and invoice identifier storedin the single data element included in the received return message.

In one embodiment, the method 800 may further include: receiving, by thereceiving device of the processing server, a blockchain (e.g., theopaque blockchain 702), wherein the blockchain includes a plurality ofblocks (e.g., blocks 704) and, for each block of the plurality ofblocks, a header (e.g., header 706) and one or more transaction values(e.g., transaction values 708); and validating, by a validation module(e.g., the validation module 214) of the processing server, theelectronic transaction based on existing of a transaction value for ablock included in the plurality of blocks included in the receivedblockchain that corresponds to the generated hash value. In someembodiments, the generated transaction message may further include amessage type indicator indicative of an authorization request, and thereceived return message may further include a message type indicatorindicative of an authorization response

In one embodiment, the method 800 may also include generating, by thedata generation module of the processing server, the invoice identifierbased on at least additional data included in the transaction datasuperimposed on the received data signal. In some embodiments, the thirddata element may be reserved for private use according to the one ormore standards.

Second Exemplary Method for Confirmation of an Electronic TransactionUsing a Blockchain

FIG. 9 illustrates a method 900 for the confirmation of an electronictransaction by an issuing financial institution for settlement via theuse of an opaque blockchain.

In step 902, a transaction message may be received by a receiving device(e.g., the receiving device 302) of a processing server (e.g., theissuing processing server 104) from a financial institution via apayment network (e.g., the payment network 112), wherein the transactionmessage is formatted based on one or more standards and includes aplurality of data elements including at least a first data elementconfigured to store the transaction amount, a second data elementconfigured to store the currency code, and a third data elementconfigured to store an invoice identifier. In step 904, a return messagemay be generated by a data generation module (e.g., the data generationmodule 310) of the processing server, wherein the return message isformatted based on the one or more standards and includes at least asingle data element configured to store a transaction amount, currencycode, and invoice identifier.

In step 906, a hash value may be generated by a hashing module (e.g.,the hashing module 312) of the processing server based on application ofone or more hashing algorithms to the transaction amount, currency code,and invoice identifier stored in the single data element in thegenerated return message. In step 908, the generated return message maybe electronically transmitted to a financial institution via the paymentnetwork by a transmitting device (e.g., the transmitting device 318) ofthe processing server. In step 910, the generated hash value may beelectronically transmitted by the transmitting device of the processingserver to a computing device (e.g., the blockchain system 114)configured to post the generated hash value to a blockchain (e.g.,blockchain 702) via a communication network.

In one embodiment, the method 900 may also include: receiving, by thereceiving device of the processing server, the blockchain, wherein theblockchain includes a plurality of blocks (e.g., blocks 704) and, foreach block of the plurality of blocks, a header (e.g., header 706) andone or more transaction values (e.g., transaction values 708); andvalidating, by a validation module (e.g., validation module 314) of theprocessing server, the electronic transaction based on existing of atransaction value for a block included in the plurality of blocksincluded in the received blockchain that corresponds to the generatedhash value. In some embodiments, the received transaction message mayfurther include a message type indicator indicative of an authorizationrequest, and the generated return message may further include a messagetype indicator indicative of an authorization response.

In one embodiment, the transaction amount, currency code, and invoiceidentifier stored in the single data element included in the generatedreturn message may be signed by a transaction processing module of theprocessing server. In some embodiments, the third data element may bereserved for private use according to the one or more standards.

Exemplary Method for Storing Confirmations of Electronic TransactionUsing a Blockchain

FIG. 10 illustrates the storage of data for use in confirmation ofelectronic transactions for settlement via an opaque blockchain.

In step 1002, a blockchain (e.g., opaque blockchain 702) may be storedin a memory (e.g., the memory 320) of a processing server (e.g., theissuer processing server 104), wherein the blockchain includes aplurality of blocks (e.g., blocks 704) and, for each block of theplurality of blocks, a header (e.g., header 706) and a plurality oftransaction values (e.g., transaction values 708), where eachtransaction value of the plurality of transaction values is a hash valuerelated to an electronic transaction and generated based on at least atransaction amount, currency code, and invoice identifier associatedwith the related electronic transaction. In step 1004, a set of new hashvalues may be received by a receiving device (e.g., the receiving device302) of the processing server, wherein each new hash value is related toan additional electronic transaction, and where each new hash value isgenerated based on application of one or more hashing algorithms to atransaction amount, currency code, and invoice identifier associatedwith the respective additional electronic transaction.

In step 1006, a query may be executed on the memory by a querying module(e.g., querying module 322) of the processing server to identify apreceding block of the plurality of blocks included in the blockchainbased on data stored in the header included in each respective block. Instep 1008, a proof of work value (e.g., proof of work value 714) may begenerated by a generation module (e.g., the data generation module 310)of the processing server based on performing one or more predeterminedactions.

In step 1010, a new block may be generated by the generation module ofthe processing server, wherein the new block includes at least a newheader and the set of new hash values, and wherein the new headerincludes at least a reference (e.g., preceding reference 712) to theidentified preceding block and the generated proof of work value. Instep 1012, the generated new block may be electronically transmitted bya transmitting device (e.g., the transmitting device 318) of theprocessing server to one or more computing devices (e.g., blockchainsystems 114) associated with the blockchain.

In one embodiment, the header included in each block of the plurality ofblocks may include a time value, and identifying the preceding block mayinclude identifying a block where the time value included in theincluded header is most recent to a present time. In some embodiments,the header included in each block of the plurality of blocks may includea reference identifier (e.g., reference identifier 710), and thereference to the identified preceding block included in the new headermay correspond to the reference identifier included in the headerincluded in the identified preceding block.

In one embodiment, the one or more predetermined actions may includesolving for a complex mathematical problem. In a further embodiment, adifficulty of the complex mathematical problem may be set by the one ormore computing devices associated with the blockchain.

Payment Transaction Processing System and Process

FIG. 11 illustrates a transaction processing system and a process 1100for the processing of payment transactions in the system. The process1100 and steps included therein may be performed by one or morecomponents of the system 100 discussed above, such as the acquirerprocessing server 102, issuer processing server 104, consumer 106,merchant 110, payment network 112, etc. The processing of paymenttransactions using the system and process 1100 illustrated in FIG. 11and discussed below may utilize the payment rails, which may becomprised of the computing devices and infrastructure utilized toperform the steps of the process 1100 as specially configured andprogrammed by the entities discussed below, including the transactionprocessing server 1112, which may be associated with one or more paymentnetworks configured to processing payment transactions. It will beapparent to persons having skill in the relevant art that the process1100 may be incorporated into the processes illustrated in FIGS. 4A, 4B,5, 6, and 8-10 , discussed above, with respect to the step or stepsinvolved in the processing of a payment transaction. In addition, theentities discussed herein for performing the process 1100 may includeone or more computing devices or systems configured to perform thefunctions discussed below. For instance, the merchant 1106 may becomprised of one or more point of sale devices, a local communicationnetwork, a computing server, and other devices configured to perform thefunctions discussed below.

In step 1120, an issuing financial institution 1102 may issue a paymentcard or other suitable payment instrument to a consumer 1104. Theissuing financial institution may be a financial institution, such as abank, or other suitable type of entity that administers and managespayment accounts and/or payment instruments for use with paymentaccounts that can be used to fund payment transactions. The consumer1104 may have a transaction account with the issuing financialinstitution 1102 for which the issued payment card is associated, suchthat, when used in a payment transaction, the payment transaction isfunded by the associated transaction account. In some embodiments, thepayment card may be issued to the consumer 1104 physically. In otherembodiments, the payment card may be a virtual payment card or otherwiseprovisioned to the consumer 1104 in an electronic format.

In step 1122, the consumer 1104 may present the issued payment card to amerchant 1106 for use in funding a payment transaction. The merchant1106 may be a business, another consumer, or any entity that may engagein a payment transaction with the consumer 1104. The payment card may bepresented by the consumer 1104 via providing the physical card to themerchant 1106, electronically transmitting (e.g., via near fieldcommunication, wireless transmission, or other suitable electronictransmission type and protocol) payment details for the payment card, orinitiating transmission of payment details to the merchant 1106 via athird party. The merchant 1106 may receive the payment details (e.g.,via the electronic transmission, via reading them from a physicalpayment card, etc.), which may include at least a transaction accountnumber associated with the payment card and/or associated transactionaccount. In some instances, the payment details may include one or moreapplication cryptograms, which may be used in the processing of thepayment transaction.

In step 1124, the merchant 1106 may enter transaction details into apoint of sale computing system. The transaction details may include thepayment details provided by the consumer 1104 associated with thepayment card and additional details associated with the transaction,such as a transaction amount, time and/or date, product data, offerdata, loyalty data, reward data, merchant data, consumer data, point ofsale data, etc. Transaction details may be entered into the point ofsale system of the merchant 1106 via one or more input devices, such asan optical bar code scanner configured to scan product bar codes, akeyboard configured to receive product codes input by a user, etc. Themerchant point of sale system may be a specifically configured computingdevice and/or special purpose computing device intended for the purposeof processing electronic financial transactions and communicating with apayment network (e.g., via the payment rails). The merchant point ofsale system may be an electronic device upon which a point of salesystem application is run, wherein the application causes the electronicdevice to receive and communicated electronic financial transactioninformation to a payment network. In some embodiments, the merchant 1106may be an online retailer in an e-commerce transaction. In suchembodiments, the transaction details may be entered in a shopping cartor other repository for storing transaction data in an electronictransaction as will be apparent to persons having skill in the relevantart.

In step 1126, the merchant 1106 may electronically transmit a datasignal superimposed with transaction data to a gateway processor 1108.The gateway processor 1108 may be an entity configured to receivetransaction details from a merchant 1106 for formatting and transmissionto an acquiring financial institution 1110. In some instances, a gatewayprocessor 1108 may be associated with a plurality of merchants 1106 anda plurality of acquiring financial institutions 1110. In such instances,the gateway processor 1108 may receive transaction details for aplurality of different transactions involving various merchants, whichmay be forwarded on to appropriate acquiring financial institutions1110. By having relationships with multiple acquiring financialinstitutions 1110 and having the requisite infrastructure to communicatewith financial institutions using the payment rails, such as usingapplication programming interfaces associated with the gateway processor1108 or financial institutions used for the submission, receipt, andretrieval of data, a gateway processor 1108 may act as an intermediaryfor a merchant 1106 to be able to conduct payment transactions via asingle communication channel and format with the gateway processor 1108,without having to maintain relationships with multiple acquiringfinancial institutions 1110 and payment processors and the hardwareassociated thereto. Acquiring financial institutions 1110 may befinancial institutions, such as banks, or other entities thatadministers and manages payment accounts and/or payment instruments foruse with payment accounts. In some instances, acquiring financialinstitutions 1110 may manage transaction accounts for merchants 1106. Insome cases, a single financial institution may operate as both anissuing financial institution 1102 and an acquiring financialinstitution 1110.

The data signal transmitted from the merchant 1106 to the gatewayprocessor 1108 may be superimposed with the transaction details for thepayment transaction, which may be formatted based on one or morestandards. In some embodiments, the standards may be set forth by thegateway processor 1108, which may use a unique, proprietary format forthe transmission of transaction data to/from the gateway processor 1108.In other embodiments, a public standard may be used, such as theInternational Organization for Standardization's ISO 81183 standard. Thestandard may indicate the types of data that may be included, theformatting of the data, how the data is to be stored and transmitted,and other criteria for the transmission of the transaction data to thegateway processor 1108.

In step 1128, the gateway processor 1108 may parse the transaction datasignal to obtain the transaction data superimposed thereon and mayformat the transaction data as necessary. The formatting of thetransaction data may be performed by the gateway processor 1108 based onthe proprietary standards of the gateway processor 1108 or an acquiringfinancial institution 1110 associated with the payment transaction. Theproprietary standards may specify the type of data included in thetransaction data and the format for storage and transmission of thedata. The acquiring financial institution 1110 may be identified by thegateway processor 1108 using the transaction data, such as by parsingthe transaction data (e.g., deconstructing into data elements) to obtainan account identifier included therein associated with the acquiringfinancial institution 1110. In some instances, the gateway processor1108 may then format the transaction data based on the identifiedacquiring financial institution 1110, such as to comply with standardsof formatting specified by the acquiring financial institution 1110. Insome embodiments, the identified acquiring financial institution 1110may be associated with the merchant 1106 involved in the paymenttransaction, and, in some cases, may manage a transaction accountassociated with the merchant 1106.

In step 1130, the gateway processor 1108 may electronically transmit adata signal superimposed with the formatted transaction data to theidentified acquiring financial institution 1110. The acquiring financialinstitution 1110 may receive the data signal and parse the signal toobtain the formatted transaction data superimposed thereon. In step1132, the acquiring financial institution may generate an authorizationrequest for the payment transaction based on the formatted transactiondata. The authorization request may be a specially formatted transactionmessage that is formatted pursuant to one or more standards, such as theISO 81183 standard and standards set forth by a payment processor usedto process the payment transaction, such as a payment network. Theauthorization request may be a transaction message that includes amessage type indicator indicative of an authorization request, which mayindicate that the merchant 1106 involved in the payment transaction isrequesting payment or a promise of payment from the issuing financialinstitution 1102 for the transaction. The authorization request mayinclude a plurality of data elements, each data element being configuredto store data as set forth in the associated standards, such as forstoring an account number, application cryptogram, transaction amount,issuing financial institution 1102 information, etc.

In step 1134, the acquiring financial institution 1110 mayelectronically transmit the authorization request to a transactionprocessing server 1112 for processing. The transaction processing server1112 may be comprised of one or more computing devices as part of apayment network configured to process payment transactions. In someembodiments, the authorization request may be transmitted by atransaction processor at the acquiring financial institution 1110 orother entity associated with the acquiring financial institution. Thetransaction processor may be one or more computing devices that includea plurality of communication channels for communication with thetransaction processing server 1112 for the transmission of transactionmessages and other data to and from the transaction processing server1112. In some embodiments, the payment network associated with thetransaction processing server 1112 may own or operate each transactionprocessor such that the payment network may maintain control over thecommunication of transaction messages to and from the transactionprocessing server 1112 for network and informational security.

In step 1136, the transaction processing server 1112 may performvalue-added services for the payment transaction. Value-added servicesmay be services specified by the issuing financial institution 1102 thatmay provide additional value to the issuing financial institution 1102or the consumer 1104 in the processing of payment transactions.Value-added services may include, for example, fraud scoring,transaction or account controls, account number mapping, offerredemption, loyalty processing, etc. For instance, when the transactionprocessing server 1112 receives the transaction, a fraud score for thetransaction may be calculated based on the data included therein and oneor more fraud scoring algorithms and/or engines. In some instances, thetransaction processing server 1112 may first identify the issuingfinancial institution 1102 associated with the transaction, and thenidentify any services indicated by the issuing financial institution1102 to be performed. The issuing financial institution 1102 may beidentified, for example, by data included in a specific data elementincluded in the authorization request, such as an issuer identificationnumber. In another example, the issuing financial institution 1102 maybe identified by the primary account number stored in the authorizationrequest, such as by using a portion of the primary account number (e.g.,a bank identification number) for identification.

In step 1138, the transaction processing server 1112 may electronicallytransmit the authorization request to the issuing financial institution1102. In some instances, the authorization request may be modified, oradditional data included in or transmitted accompanying theauthorization request as a result of the performance of value-addedservices by the transaction processing server 1112. In some embodiments,the authorization request may be transmitted to a transaction processor(e.g., owned or operated by the transaction processing server 1112)situated at the issuing financial institution 1102 or an entityassociated thereof, which may forward the authorization request to theissuing financial institution 1102.

In step 1140, the issuing financial institution 1102 may authorize thetransaction account for payment of the payment transaction. Theauthorization may be based on an available credit amount for thetransaction account and the transaction amount for the paymenttransaction, fraud scores provided by the transaction processing server1112, and other considerations that will be apparent to persons havingskill in the relevant art. The issuing financial institution 1102 maymodify the authorization request to include a response code indicatingapproval (e.g., or denial if the transaction is to be denied) of thepayment transaction. The issuing financial institution 1102 may alsomodify a message type indicator for the transaction message to indicatethat the transaction message is changed to be an authorization response.In step 1142, the issuing financial institution 1102 may transmit (e.g.,via a transaction processor) the authorization response to thetransaction processing server 1112.

In step 1144, the transaction processing server 1112 may forward theauthorization response to the acquiring financial institution 1110(e.g., via a transaction processor). In step 1146, the acquiringfinancial institution may generate a response message indicatingapproval or denial of the payment transaction as indicated in theresponse code of the authorization response, and may transmit theresponse message to the gateway processor 1108 using the standards andprotocols set forth by the gateway processor 1108. In step 1148, thegateway processor 1108 may forward the response message to the merchant1106 using the appropriate standards and protocols. In step 1150, themerchant 1106 may then provide the products purchased by the consumer1104 as part of the payment transaction to the consumer 1104, assumingthe payment transaction is approved.

In some embodiments, once the process 1100 has completed, payment fromthe issuing financial institution 1102 to the acquiring financialinstitution 1110 may be performed. In some instances, the payment may bemade immediately or within one business day. In other instances, thepayment may be made after a period of time, and in response to thesubmission of a clearing request from the acquiring financialinstitution 1110 to the issuing financial institution 1102 via thetransaction processing server 1112. In such instances, clearing requestsfor multiple payment transactions may be aggregated into a singleclearing request, which may be used by the transaction processing server1112 to identify overall payments to be made by whom and to whom forsettlement of payment transactions.

In some instances, the system may also be configured to perform theprocessing of payment transactions in instances where communicationpaths may be unavailable. For example, if the issuing financialinstitution is unavailable to perform authorization of the transactionaccount (e.g., in step 1140), the transaction processing server 1112 maybe configured to perform authorization of transactions on behalf of theissuing financial institution 1102. Such actions may be referred to as“stand-in processing,” where the transaction processing server “standsin” as the issuing financial institution 1102. In such instances, thetransaction processing server 1112 may utilize rules set forth by theissuing financial institution 1102 to determine approval or denial ofthe payment transaction, and may modify the transaction messageaccordingly prior to forwarding to the acquiring financial institution1110 in step 1144. The transaction processing server 1112 may retaindata associated with transactions for which the transaction processingserver 1112 stands in, and may transmit the retained data to the issuingfinancial institution 1102 once communication is reestablished. Theissuing financial institution 1102 may then process transaction accountsaccordingly to accommodate for the time of lost communication.

In another example, if the transaction processing server 1112 isunavailable for submission of the authorization request by the acquiringfinancial institution 1110, then the transaction processor at theacquiring financial institution 1110 may be configured to perform theprocessing of the transaction processing server 1112 and the issuingfinancial institution 1102. The transaction processor may include rulesand data suitable for use in making a determination of approval ordenial of the payment transaction based on the data included therein.For instance, the issuing financial institution 1102 and/or transactionprocessing server 1112 may set limits on transaction type, transactionamount, etc. that may be stored in the transaction processor and used todetermine approval or denial of a payment transaction based thereon. Insuch instances, the acquiring financial institution 1110 may receive anauthorization response for the payment transaction even if thetransaction processing server 1112 is unavailable, ensuring thattransactions are processed and no downtime is experienced even ininstances where communication is unavailable. In such cases, thetransaction processor may store transaction details for the paymenttransactions, which may be transmitted to the transaction processingserver 1112 (e.g., and from there to the associated issuing financialinstitutions 1102) once communication is reestablished.

In some embodiments, transaction processors may be configured to includea plurality of different communication channels, which may utilizemultiple communication cards and/or devices, to communicate with thetransaction processing server 1112 for the sending and receiving oftransaction messages. For example, a transaction processor may becomprised of multiple computing devices, each having multiplecommunication ports that are connected to the transaction processingserver 1112. In such embodiments, the transaction processor may cyclethrough the communication channels when transmitting transactionmessages to the transaction processing server 1112, to alleviate networkcongestion and ensure faster, smoother communications. Furthermore, ininstances where a communication channel may be interrupted or otherwiseunavailable, alternative communication channels may thereby beavailable, to further increase the uptime of the network.

In some embodiments, transaction processors may be configured tocommunicate directly with other transaction processors. For example, atransaction processor at an acquiring financial institution 1110 mayidentify that an authorization request involves an issuing financialinstitution 1102 (e.g., via the bank identification number included inthe transaction message) for which no value-added services are required.The transaction processor at the acquiring financial institution 1110may then transmit the authorization request directly to the transactionprocessor at the issuing financial institution 1102 (e.g., without theauthorization request passing through the transaction processing server1112), where the issuing financial institution 1102 may process thetransaction accordingly.

The methods discussed above for the processing of payment transactionsthat utilize multiple methods of communication using multiplecommunication channels, and includes fail safes to provide for theprocessing of payment transactions at multiple points in the process andat multiple locations in the system, as well as redundancies to ensurethat communications arrive at their destination successfully even ininstances of interruptions, may provide for a robust system that ensuresthat payment transactions are always processed successfully with minimalerror and interruption. This advanced network and its infrastructure andtopology may be commonly referred to as “payment rails,” wheretransaction data may be submitted to the payment rails from merchants atmillions of different points of sale, to be routed through theinfrastructure to the appropriate transaction processing servers 1112for processing. The payment rails may be such that a general purposecomputing device may be unable to properly format or submitcommunications to the rails, without specialized programming and/orconfiguration. Through the specialized purposing of a computing device,the computing device may be configured to submit transaction data to theappropriate entity (e.g., a gateway processor 1108, acquiring financialinstitution 1110, etc.) for processing using this advanced network, andto quickly and efficiently receive a response regarding the ability fora consumer 1104 to fund the payment transaction.

Computer System Architecture

FIG. 12 illustrates a computer system 1200 in which embodiments of thepresent disclosure, or portions thereof, may be implemented ascomputer-readable code. For example, the acquirer processing server 102and issuer processing server 104 of FIG. 1 may be implemented in thecomputer system 1200 using hardware, software, firmware, non-transitorycomputer readable media having instructions stored thereon, or acombination thereof and may be implemented in one or more computersystems or other processing systems. Hardware, software, or anycombination thereof may embody modules and components used to implementthe methods of FIGS. 4A, 4B, 5, 6, and 8-11 .

If programmable logic is used, such logic may execute on a commerciallyavailable processing platform or a special purpose device. A personhaving ordinary skill in the art may appreciate that embodiments of thedisclosed subject matter can be practiced with various computer systemconfigurations, including multi-core multiprocessor systems,minicomputers, mainframe computers, computers linked or clustered withdistributed functions, as well as pervasive or miniature computers thatmay be embedded into virtually any device. For instance, at least oneprocessor device and a memory may be used to implement the abovedescribed embodiments.

A processor unit or device as discussed herein may be a singleprocessor, a plurality of processors, or combinations thereof. Processordevices may have one or more processor “cores.” The terms “computerprogram medium,” “non-transitory computer readable medium,” and“computer usable medium” as discussed herein are used to generally referto tangible media such as a removable storage unit 1218, a removablestorage unit 1222, and a hard disk installed in hard disk drive 1212.

Various embodiments of the present disclosure are described in terms ofthis example computer system 1200. After reading this description, itwill become apparent to a person skilled in the relevant art how toimplement the present disclosure using other computer systems and/orcomputer architectures. Although operations may be described as asequential process, some of the operations may in fact be performed inparallel, concurrently, and/or in a distributed environment, and withprogram code stored locally or remotely for access by single ormulti-processor machines. In addition, in some embodiments the order ofoperations may be rearranged without departing from the spirit of thedisclosed subject matter.

Processor device 1204 may be a special purpose or a general purposeprocessor device specifically configured to perform the functionsdiscussed herein. The processor device 1204 may be connected to acommunications infrastructure 1206, such as a bus, message queue,network, multi-core message-passing scheme, etc. The network may be anynetwork suitable for performing the functions as disclosed herein andmay include a local area network (LAN), a wide area network (WAN), awireless network (e.g., WiFi), a mobile communication network, asatellite network, the Internet, fiber optic, coaxial cable, infrared,radio frequency (RF), or any combination thereof. Other suitable networktypes and configurations will be apparent to persons having skill in therelevant art. The computer system 1200 may also include a main memory1208 (e.g., random access memory, read-only memory, etc.), and may alsoinclude a secondary memory 1210. The secondary memory 1210 may includethe hard disk drive 1212 and a removable storage drive 1214, such as afloppy disk drive, a magnetic tape drive, an optical disk drive, a flashmemory, etc.

The removable storage drive 1214 may read from and/or write to theremovable storage unit 1218 in a well-known manner. The removablestorage unit 1218 may include a removable storage media that may be readby and written to by the removable storage drive 1214. For example, ifthe removable storage drive 1214 is a floppy disk drive or universalserial bus port, the removable storage unit 1218 may be a floppy disk orportable flash drive, respectively. In one embodiment, the removablestorage unit 1218 may be non-transitory computer readable recordingmedia.

In some embodiments, the secondary memory 1210 may include alternativemeans for allowing computer programs or other instructions to be loadedinto the computer system 1200, for example, the removable storage unit1222 and an interface 1220. Examples of such means may include a programcartridge and cartridge interface (e.g., as found in video gamesystems), a removable memory chip (e.g., EEPROM, PROM, etc.) andassociated socket, and other removable storage units 1222 and interfaces1220 as will be apparent to persons having skill in the relevant art.

Data stored in the computer system 1200 (e.g., in the main memory 1208and/or the secondary memory 1210) may be stored on any type of suitablecomputer readable media, such as optical storage (e.g., a compact disc,digital versatile disc, Blu-ray disc, etc.) or magnetic tape storage(e.g., a hard disk drive). The data may be configured in any type ofsuitable database configuration, such as a relational database, astructured query language (SQL) database, a distributed database, anobject database, etc. Suitable configurations and storage types will beapparent to persons having skill in the relevant art.

The computer system 1200 may also include a communications interface1224. The communications interface 1224 may be configured to allowsoftware and data to be transferred between the computer system 1200 andexternal devices. Exemplary communications interfaces 1224 may include amodem, a network interface (e.g., an Ethernet card), a communicationsport, a PCMCIA slot and card, etc. Software and data transferred via thecommunications interface 1224 may be in the form of signals, which maybe electronic, electromagnetic, optical, or other signals as will beapparent to persons having skill in the relevant art. The signals maytravel via a communications path 1226, which may be configured to carrythe signals and may be implemented using wire, cable, fiber optics, aphone line, a cellular phone link, a radio frequency link, etc.

The computer system 1200 may further include a display interface 1202.The display interface 1202 may be configured to allow data to betransferred between the computer system 1200 and external display 1230.Exemplary display interfaces 1202 may include high-definition multimediainterface (HDMI), digital visual interface (DVI), video graphics array(VGA), etc. The display 1230 may be any suitable type of display fordisplaying data transmitted via the display interface 1202 of thecomputer system 1200, including a cathode ray tube (CRT) display, liquidcrystal display (LCD), light-emitting diode (LED) display, capacitivetouch display, thin-film transistor (TFT) display, etc.

Computer program medium and computer usable medium may refer tomemories, such as the main memory 1208 and secondary memory 1210, whichmay be memory semiconductors (e.g., DRAMs, etc.). These computer programproducts may be means for providing software to the computer system1200. Computer programs (e.g., computer control logic) may be stored inthe main memory 1208 and/or the secondary memory 1210. Computer programsmay also be received via the communications interface 1224. Suchcomputer programs, when executed, may enable computer system 1200 toimplement the present methods as discussed herein. In particular, thecomputer programs, when executed, may enable processor device 1204 toimplement the methods illustrated by FIGS. 4A, 4B, 5, 6, and 8-11 , asdiscussed herein. Accordingly, such computer programs may representcontrollers of the computer system 1200. Where the present disclosure isimplemented using software, the software may be stored in a computerprogram product and loaded into the computer system 1200 using theremovable storage drive 1214, interface 1220, and hard disk drive 1212,or communications interface 1224.

The processor device 1204 may comprise one or more modules or enginesconfigured to perform the functions of the computer system 1200. Each ofthe modules or engines may be implemented using hardware and, in someinstances, may also utilize software, such as corresponding to programcode and/or programs stored in the main memory 1208 or secondary memory1210. In such instances, program code may be compiled by the processordevice 1204 (e.g., by a compiling module or engine) prior to executionby the hardware of the computer system 1200. For example, the programcode may be source code written in a programming language that istranslated into a lower level language, such as assembly language ormachine code, for execution by the processor device 1204 and/or anyadditional hardware components of the computer system 1200. The processof compiling may include the use of lexical analysis, preprocessing,parsing, semantic analysis, syntax-directed translation, codegeneration, code optimization, and any other techniques that may besuitable for translation of program code into a lower level languagesuitable for controlling the computer system 1200 to perform thefunctions disclosed herein. It will be apparent to persons having skillin the relevant art that such processes result in the computer system1200 being a specially configured computer system 1200 uniquelyprogrammed to perform the functions discussed above.

Techniques consistent with the present disclosure provide, among otherfeatures, systems and methods for confirming electronic transactionsusing an opaque blockchain. While various exemplary embodiments of thedisclosed system and method have been described above it should beunderstood that they have been presented for purposes of example only,not limitations. It is not exhaustive and does not limit the disclosureto the precise form disclosed. Modifications and variations are possiblein light of the above teachings or may be acquired from practicing ofthe disclosure, without departing from the breadth or scope.

What is claimed is:
 1. A method for confirmation of an electronictransaction using a blockchain, the method comprising: storing, in atransaction profile of a transaction database in the processing serverof an acquiring institution, an account preference, wherein the accountpreference is associated with a transaction account of a merchant;receiving, by a receiver of the acquiring institution processing server,a data signal with transaction data from the merchant, wherein thetransaction data includes data related to an electronic transactionincluding at least a transaction amount and currency code; determining,by the processing device of the acquiring institution processing server,that the electronic transaction involves settlement using a blockchainbased on the account preference stored in the transaction profileassociated with the transaction account of the merchant, the accountpreference including a transaction settlement policy based on thetransaction amount; generating, by a processing device of the acquiringinstitution processing server, a transaction message for the electronictransaction, wherein the transaction message includes at least a firstdata element storing the transaction amount, a second data elementstoring the currency code, and a third data element storing an invoiceidentifier; electronically transmitting, by a transmitter of theacquiring institution processing server, the generated transactionmessage to an issuing financial institution via a payment network;receiving, by the receiver of the acquiring institution processingserver, an authorization message from the issuing financial institutionvia the payment network, wherein the return message includes at least asingle data element storing the transaction amount, the currency code,and the invoice identifier; and generating, by the processing device ofthe acquiring institution processing server, a hash value based onapplication of one or more hashing algorithms to the transaction amount,currency code, and invoice identifier stored in the single data elementincluded in the received return message.
 2. The method of claim 1,further comprising: receiving, by the receiver of the acquiringinstitution processing server, the blockchain from a blockchain network,wherein the blockchain includes a plurality of blocks and, for eachblock of the plurality of blocks, a header and one or more transactionvalues; and validating, by the processing device of the acquiringinstitution processing server, the electronic transaction based onexisting of a transaction value for a block included in the plurality ofblocks included in the received blockchain that corresponds to thegenerated hash value.
 3. A method for confirmation of an electronictransaction using a blockchain, comprising: receiving, by a receivingdevice of a processing server, a transaction message from a financialinstitution via a payment network, wherein the transaction message isformatted based on one or more standards and includes a plurality ofdata elements including at least a first data element configured tostore the transaction amount, a second data element configured to storethe currency code, and a third data element configured to store aninvoice identifier; generating, by a data generation module of theprocessing server, a return message, wherein the return message isformatted based on the one or more standards and includes at least asingle data element configured to store a transaction amount, currencycode, and invoice identifier; generating, by a hashing module of theprocessing server, a hash value based on application of one or morehashing algorithms to the transaction amount, currency code, and invoiceidentifier stored in the single data element in the generated returnmessage; electronically transmitting, by a transmitting device of theprocessing server, the generated return message to the financialinstitution via the payment network; and electronically transmitting, bythe transmitting device of the processing server, the generated hashvalue to a computing device configured to post the generated hash valueto a blockchain via a communication network.
 4. The method of claim 3,further comprising: receiving, by the receiving device of the processingserver, the blockchain, wherein the blockchain includes a plurality ofblocks and, for each block of the plurality of blocks, a header and oneor more transaction values; and validating, by a validation module ofthe processing server, the electronic transaction based on existing of atransaction value for a block included in the plurality of blocksincluded in the received blockchain that corresponds to the generatedhash value.
 5. The method of claim 3, wherein the received transactionmessage further includes a message type indicator indicative of anauthorization request, and the generated return message further includesa message type indicator indicative of an authorization response.
 6. Themethod of claim 3, wherein the transaction amount, currency code, andinvoice identifier stored in the single data element included in thegenerated return message are signed by a transaction processing moduleof the processing server.
 7. The method of claim 3, wherein the thirddata element is reserved for private use according to the one or morestandards.
 8. A system for confirmation of an electronic transactionusing a blockchain, comprising: a transaction database of an acquiringinstitution processing server of a payment network storing a transactionprofile, wherein the transaction profile includes an account preferenceand is associated with a transaction account of a merchant; a receiverof the acquiring institution processing server receiving a data signalwith transaction data from the merchant, wherein the transaction dataincludes data related to an electronic transaction including at least atransaction amount and currency code; a processing device of theacquiring institution processing server determining that the electronictransaction involves settlement using a blockchain based on the accountpreference stored in the transaction profile associated with thetransaction account of the merchant, the account preference including atransaction settlement policy based on the transaction amount; theprocessing device of the acquiring institution processing servergenerating a transaction message for the electronic transaction, whereinthe transaction message includes at least a first data element storingthe transaction amount, a second data element storing the currency code,and a third data element storing an invoice identifier; a transmitter ofthe acquiring institution processing server electronically transmittingthe generated transaction message to an issuing financial institutionvia a payment network; the receiver of the acquiring institutionprocessing server receiving an authorization message from the issuingfinancial institution via the payment network, wherein the returnmessage includes at least a single data element storing the transactionamount, the currency code, and the invoice identifier; and theprocessing device of the acquiring institution processing server of thepayment network generating a hash value based on application of one ormore hashing algorithms to the transaction amount, currency code, andinvoice identifier stored in the single data element included in thereceived return message value.
 9. The system of claim 8, furthercomprising: the receiver of the acquiring institution processing serverreceiving the blockchain from a blockchain network, wherein theblockchain includes a plurality of blocks and, for each block of theplurality of blocks, a header and one or more transaction values, andthe processing device of the acquiring institution processing servervalidating the electronic transaction based on existing of a transactionvalue for a block included in the plurality of blocks included in thereceived blockchain that corresponds to the generated hash value.
 10. Asystem for confirmation of an electronic transaction using a blockchain,comprising: a receiving device of a processing server configured toreceive a transaction message from a financial institution via a paymentnetwork, wherein the transaction message is formatted based on one ormore standards and includes a plurality of data elements including atleast a first data element configured to store the transaction amount, asecond data element configured to store the currency code, and a thirddata element configured to store an invoice identifier; a datageneration module of the processing server configured to generate areturn message, wherein the return message is formatted based on the oneor more standards and includes at least a single data element configuredto store a transaction amount, currency code, and invoice identifier; ahashing module of the processing server configured to generate a hashvalue based on application of one or more hashing algorithms to thetransaction amount, currency code, and invoice identifier stored in thesingle data element in the generated return message; and a transmittingdevice of the processing server configured to electronically transmitthe generated return message to the financial institution via thepayment network, and electronically transmit the generated hash value toa computing device configured to post the generated hash value to ablockchain via a communication network.
 11. The system of claim 10,further comprising: a validation module of the processing server,wherein the receiving device of the processing server is furtherconfigured to receive the blockchain, wherein the blockchain includes aplurality of blocks and, for each block of the plurality of blocks, aheader and one or more transaction values, and the validation module ofthe processing server is configured to validate the electronictransaction based on existing of a transaction value for a blockincluded in the plurality of blocks included in the received blockchainthat corresponds to the generated hash value.
 12. The system of claim10, wherein the received transaction message further includes a messagetype indicator indicative of an authorization request, and the generatedreturn message further includes a message type indicator indicative ofan authorization response.
 13. The system of claim 10, wherein thetransaction amount, currency code, and invoice identifier stored in thesingle data element included in the generated return message are signedby a transaction processing module of the processing server.
 14. Thesystem of claim 10, wherein the third data element is reserved forprivate use according to the one or more standards.
 15. A method forstoring confirmations of electronic transactions using a blockchain,comprising: storing, in a memory of a processing server, a blockchain,wherein the blockchain includes a plurality of blocks and, for eachblock of the plurality of blocks, a header and a plurality oftransaction values, where each transaction value of the plurality oftransaction values is a hash value related to an electronic transactionand generated based on at least a transaction amount, currency code, andinvoice identifier associated with the related electronic transaction;receiving, by a receiving device of the processing server, a set of newhash values, wherein each new hash value is related to an additionalelectronic transaction, and where each new hash value is generated basedon application of one or more hashing algorithms to a transactionamount, currency code, and invoice identifier associated with therespective additional electronic transaction; executing, by a queryingmodule of the processing server, a query on the memory to identify apreceding block of the plurality of blocks included in the blockchainbased on data stored in the header included in each respective block;generating, by a generation module of the processing server, a proof ofwork value based on performing one or more predetermined actions;generating, by the generation module of the processing server, a newblock, wherein the new block includes at least a new header and the setof new hash values, and wherein the new header includes at least areference to the identified preceding block and the generated proof ofwork value; and electronically transmitting, by a transmitting device ofthe processing server, the generated new block to one or more computingdevices associated with the blockchain.
 16. The method of claim 15,wherein the header included in each block of the plurality of blocksincludes a time value, and identifying the preceding block includesidentifying a block where the time value included in the included headeris most recent to a present time.
 17. The method of claim 15, whereinthe header included in each block of the plurality of blocks includes areference identifier, and the reference to the identified precedingblock included in the new header corresponds to the reference identifierincluded in the header included in the identified preceding block. 18.The method of claim 15, wherein the one or more predetermined actionsincludes solving for a complex mathematical problem.
 19. The method ofclaim 18, wherein a difficulty of the complex mathematical problem isset by the one or more computing devices associated with the blockchain.20. A system for storing confirmations of electronic transactions usinga blockchain, comprising: a memory of a processing server configured tostore a blockchain, wherein the blockchain includes a plurality ofblocks and, for each block of the plurality of blocks, a header and aplurality of transaction values, where each transaction value of theplurality of transaction values is a hash value related to an electronictransaction and generated based on at least a transaction amount,currency code, and invoice identifier associated with the relatedelectronic transaction; a receiving device of the processing serverconfigured to receive a set of new hash values, wherein each new hashvalue is related to an additional electronic transaction, and where eachnew hash value is generated based on application of one or more hashingalgorithms to a transaction amount, currency code, and invoiceidentifier associated with the respective additional electronictransaction; a querying module of the processing server configured toexecute a query on the memory to identify a preceding block of theplurality of blocks included in the blockchain based on data stored inthe header included in each respective block; a generation module of theprocessing server configured to generate a proof of work value based onperforming one or more predetermined actions, and generate a new block,wherein the new block includes at least a new header and the set of newhash values, and wherein the new header includes at least a reference tothe identified preceding block and the generated proof of work value;and a transmitting device of the processing server configured toelectronically transmit the generated new block to one or more computingdevices associated with the blockchain.